D3b: api command edge-value validation (C11+C12+C13)

[espadonne]

Summary

Three MED findings from the C-audit, all in pkg/cmd/api. Single-file blast radius, cohesive fix.

• C11 — api --paginate against a non-array endpoint silently wrapped the single object in [obj]. Scripts like api repos/o/r --paginate | jq '.[]' got exactly one element and assumed pagination "worked". Now errors: api: --paginate requires a JSON array response; <endpoint> did not return one.
• C12 — api -f q=hello /search on a GET silently sent a JSON body. Server rejected with a confusing parse error. gh-compat behavior: fields on GET become ?key=value query params. New helper queryStringFromFields handles the conversion (including @file expansion for -F).
• C13 — api -t '{{.totally_missing}}' printed the literal <no value> and exited 0. text/template's default behavior — useless under CLI scripting where missing fields should fail loudly. Now uses Option("missingkey=error").

Test plan

• TestRunTemplateRejectsMissingKey — {{.totally_missing}} errors; stdout never contains <no value>.
• TestRunGETWithFieldsBecomesQueryString — GET /search -f q=hello -f sort=stars lands as ?q=hello&sort=stars.
• TestRunPaginateRejectsNonArrayResponse — --paginate on /user (object response) errors mentioning "JSON array".
• All existing pkg/cmd/api tests (including TestRunPaginateConcatArray, template execution, mutex) still green.
• make ci green locally.

Notes for follow-up (deferred from this PR)

• C10 (--max-pages 0/-1) — the audit flagged this as "silently no-cap", but the help text documents 0 → default (30) and -1 → no cap. Needs deeper investigation: does the audit's repro actually disagree with the documented behavior? Skipping until verified.
• C9 (--limit 0/-1) — separate batch (touches many commands, not just api). Lands as D3b-2.
• C25 (secret set name regex) — single-file fix, separate small PR.