fix: idempotency key scoping, profile resolution, and unbounded paging

[patramsey]

Five bugs, found by probing the built binary against a local stub rather than by
reading. Each has a regression test, and each test was verified by reverting its
fix and confirming the test fails.

1. dns import sent one idempotency key for every record

A key identifies an operation, but root.go minted one per invocation and
pinned it on the context, so every write in a command shared it. Import posts
once per record — three different bodies, one key:

POST key=a160be44-…e429aef body={"answer":"1.1.1.1","host":"a",…}
POST key=a160be44-…e429aef body={"answer":"2.2.2.2","host":"b",…}
POST key=a160be44-…e429aef body={"answer":"3.3.3.3","host":"c",…}

If the API enforces keys on that endpoint as its own docs describe — "reusing
the same key returns the original result instead of repeating the operation" —
a 50-record zone file creates record 1, gets record 1's response 49 more times,
and prints Imported 50 record(s). Silent data loss reported as completion.
api.Decode(resp, nil) discards the response, so the duplicate IDs are not
noticed either.

The editor now mints a key per outgoing write. Retries are unaffected: it runs
once where the request is built, and retryTransport replays that same
*http.Request with its headers already set, so every attempt at one operation
carries one key. --idempotency-key still pins every write in an invocation to
one value — that is what makes re-running a failed command collapse onto the
original — and its help text now says so.

Note: the client behaviour is confirmed; whether name.com actually dedupes
on this endpoint is not, since verifying it means creating real records. The
scoping is wrong either way.

2. Credentials that exist reported as missing

firstNonEmpty(flag, env, f.Default) resolved to "" when a file carried no
top-level default: key, and f.Profiles[""] is the zero value:

$ namecom config list-profiles     # {"name": "default", "username": "alice", …}
$ namecom auth status
error: no credentials configured (… or run 'namecom auth login')   # exit 3

The recommended fix would have overwritten the working profile. auth login
writes the key, so only hand-edited files were affected — which is the only way
to configure token_cmd.

A profile named default is now used without the key, as is a lone profile
under any name. Two or more with no default stays an error, but one that names
them:

no credentials configured: 2 profiles exist (home, work) but none is the
default — pass --profile, set NAMECOM_PROFILE, or run 'namecom config use <profile>'

3. Seven list commands could page forever

The only stopping condition was nextPage == nil || *nextPage == 0, which
trusts the server to eventually stop saying "there is more". Against a stub
that kept answering nextPage: 2, dns list --all never returned — still
going after 20 seconds at the full 10 req/s rate limit.

domain list was immune because it bounds its walk on lastPage. Nothing else
did: order, dns, email, url, vanity-ns, transfer, contact,
namecom status, and CompleteRecordIDs — where the symptom is a hung shell
completion. All ten walks now go through cmdutil.NextPage, which requires the
page number to advance and to stay within lastPage when the API reports one.

4. A 429 with a long Retry-After was swallowed

Before — 30 seconds of silence, then:

error: Get "http://…": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Exit 1, a transport error, discarding the rate-limit answer the server had
already given. After — immediate, exit 5:

error: slow down
  hint: rate limited — the API asked to wait 10m0s before retrying

A wait that cannot fit the remaining deadline is no longer taken; the response
is returned instead. A server-supplied wait is also clamped to 30s, matching
the cap computed backoff has always had. APIError gains RetryAfter so the
hint can name the delay rather than advising the user to "wait a moment".

5. Non-JSON error bodies echoed verbatim

An nginx 502 page became the error message: one 20,745-byte line, in the
terminal and inside the JSON error envelope alike. parseError capped the read
at 1 MiB but nothing capped the message. Now collapsed to one line and
truncated to 400 characters with the dropped byte count disclosed — 930 bytes
total for the same response.

Docs

CLAUDE.md:66 claimed transport.go retries a POST when X-Idempotency-Key
is set. It never has — idempotent() covers GET/HEAD/PUT/DELETE only, and
transport_test.go:149 pins that a key does not make a POST retryable on
5xx. This matters for #40, where the claim had already been repeated; corrected
there too. --timeout is also now described as the total budget for one call
including retries, which is what http.Client.Timeout has always meant.

Tests

New: TestIdempotencyKeyIsPerOperation, TestIdempotencyKeyPinnedAcrossOperations,
TestIdempotencyKeyAbsentOnReads, TestResolveImpliedDefault, TestNextPage,
TestRetryAfterDoesNotOutliveDeadline, TestRetryAfterHonouredWhenItFits,
TestRetryAfterClamped, TestSummarizeBody, TestRetryAfterHint.

TestContextCancelStopsRetry is restructured rather than merely updated. Its
old assertion — that an unfittable wait produces a context error — is the exact
behaviour #4 fixes, so it now covers both paths: an unfittable wait returns the
response, and a cancellation during an eligible backoff still abandons it.
The elapsed-time bound the original comment describes is preserved, since it is
what actually holds sleep() to account.

make test, make lint, and make build pass.

[codecov]

Codecov Report

❌ Patch coverage is 93.75000% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cmd/root.go	33.3%	4 Missing ⚠️
cmd/status.go	77.7%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!