spike: evaluate the Core SDK against the dns command group

[patramsey]

Draft, and not intended to merge as-is. This is the dns spike from #40.
internal/sdkspike is not imported by cmd/, nothing existing is changed, and
the package should be deleted once the decision is made either way. It is on a
branch so the evidence is reviewable rather than described.

Ported the dns read and read-modify-write paths onto
github.com/namedotcom/core-api-go v1.33.2, wired the way the evaluation
recommends: the SDK for types, our own transport for rate limiting, retry
policy, and the deadline guard from #41.

The headline result is a defect, not a design question

option.WithoutRetries() is silently ignored at client scope.

internal/retrier.go's NewRetrier reads only attempts out of the options it
is handed and discards disabled:

func NewRetrier(opts ...RetryOption) *Retrier {
	options := new(retryOptions)
	for _, opt := range opts { opt(options) }
	attempts := uint(defaultRetryAttempts)
	if options.attempts > 0 { attempts = options.attempts }
	return &Retrier{attempts: attempts}   // options.disabled dropped here
}

Run honours disabled only from per-call options, and each generated method
rebuilds its options from scratch (options := core.NewRequestOptions(opts...)),
so the client-scoped value never reaches it. Measured against a 500:

wiring	requests
WithoutRetries() on the client	2
WithoutRetries() per call	1
no option	2

This is a safety setting, and client scope is where a safety setting most needs
to hold. The fallback — carrying the option on all ~53 call sites — works, but
anything added later that forgets it silently regains the behaviour, with no
signal.

The client-scope test asserts the defect, so the day the SDK fixes it the test
fails and tells us the workaround can be dropped.

What that option is guarding

• POST retried on 5xx. shouldRetry dispatches on status code alone, no
  method check — exactly what idempotent() refuses to do. Measured: the SDK
  sent a CreateRecord POST twice against a 500. The API honours idempotency
  keys on only five operations, and record creation is not one (confirmed in
  sandbox, see Evaluate replacing the vendored spec + codegen with the official name.com Core SDK #40).
• Backoff ignores context. internal/retrier.go:146 is a bare
  time.Sleep(delay). A call with a 100ms deadline took 2s against a
  Retry-After: 2. --timeout stops being enforceable during backoff, and fix: idempotency key scoping, profile resolution, and unbounded paging #41's
  "return the 429 rather than sleep past the deadline" behaviour is undone.

Two claims from the issue body were wrong

The generated-type gotchas do not disappear. They come from the spec, not
from oapi-codegen, so they survive:

	today	SDK
record TTL	int64 value	int64 value
update body TTL	*int64	*int64
record Type	*string	*string
update body Type	named enum, cast required	named enum, cast required

Plus a new one: Host is string on the create body and *string on the
update body.

cmdutil.NextPage does not port unchanged. The SDK reports nextPage and
lastPage as *int where the generated client used *int32, so every
paginated walk needs the same re-typing. The spike carries a re-typed copy to
show the shape of it.

What does hold

• Coverage: all 53 operations the CLI calls (eight were Fern renames).
• Auth: byte-identical to what client.go builds today — asserted.
• Our transport survives: asserted explicitly with a counting
  RoundTripper, because it is the assumption the whole recommendation rests on
  and it depends on a fallback in caller.Call (client := c.client; if params.Client != nil) that the retry flag conspicuously did not get.

What is genuinely better

CreateRecord returns *Record rather than a response needing Decode();
DeleteRecord returns just error; DomainName/ID move into the request
struct instead of positional arguments. The RMW merge itself is slightly
shorter. Modest, but real.

Recommendation

The prize is still the ~39,800 lines of generated client, vendored spec, and
Python preprocessor. But the retry layer has to be neutralised per call, not per
client, until the SDK is fixed — and that is a standing hazard rather than a
one-time cost.

Worth raising WithoutRetries() upstream before committing. If it is fixed, the
migration gets materially safer; if it is not, the per-call discipline needs a
lint rule or a wrapper that makes forgetting it impossible.

Run go test ./internal/sdkspike/ -v for the measurements.

[codecov]

Codecov Report

❌ Patch coverage is 75.67568% with 18 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/sdkspike/spike.go	75.6%	9 Missing and 9 partials ⚠️

📢 Thoughts on this report? Let us know!