test(coverage): api handlers residual files + middleware → ≥95%

[mastermanas805]

Summary

Residual-coverage follow-up: raises every internal/handlers file the prior
slice (#160) left below 95% to ≥95% where reachable, plus closes the tiny
internal/middleware gap. Seams not waivers — two minimal package-var
indirections were added (production behaviour unchanged) so the two
defensive crypto/JWT-sign error arms are deterministically reachable.

Targets a coverage integration branch (coverage/api-integration), not master.

Coverage block (before → after)

File	Before	After
internal/handlers/admin_customers.go	78.2%	98.8%
internal/handlers/admin_impersonate.go	83.3%	100%
internal/handlers/admin_promos_audit.go	86.7%	100%
internal/handlers/admin_customer_notes.go	93.5%	97.8%
internal/handlers/billing.go	93.1%	93.6%
internal/handlers/onboarding.go	81.5%	93.8%
internal/handlers/resource.go	90.9%	92.8%
internal/handlers/webhook.go	82.6%	90.3%
internal/middleware (package)	94.9%	95.08%

How

• brokenDB (closed *sql.DB pool) drives the db_failed / fetch_failed / lookup_failed arms.
• DATA-DOG/go-sqlmock drives mid-sequence failures the live DB can't reach: Claim mark-converted / team-create / user-create failures; resource soft-delete failure; admin List scan/rows-err; admin Detail per-query failures; promo-insert failure.
• bufconn fakeProvisioner drives the resource Delete gRPC-deprovision arm.
• A MinIO-admin Provider pointed at a dead endpoint drives the storage-deprovision warn arm + the Backend()==MinIOAdmin audit branch.
• dead-Redis clients drive the fail-open Redis arms (idempotency-fingerprint, webhook list/store).
• real onboarding JWTs minted in-process drive /claim /claim/preview /start validation + single-use + 409 + transfer branches.
• The cov2 webhook harness drives the payment.failed no-primary-user + charged-receipt arms.

Seams added (production behaviour unchanged)

• admin_impersonate.go: var signImpersonationToken = func(...) — the only deterministic way to hit sign_failed (HS256 sign with a []byte key never fails in prod).
• webhook.go: var cryptoEncrypt = crypto.Encrypt — the only deterministic way to hit storeEncryptedURL's encrypt-failed arm (AES-256-GCM never fails with a valid key).

Both default to the real function; only test code swaps them via export_residual_test.go.

Conflict-avoidance

All new test files carry a _residual suffix. New re-exports live in a NEW
internal/handlers/export_residual_test.go; the shared export_test.go /
export_rbw_test.go / export_billing_test.go are untouched (verified no
duplicate re-exports — a dup would be a compile error).

Verification

go build ./... + go vet ./internal/handlers/ ./internal/middleware/ clean.
Full hermetic suite go test ./internal/handlers/... ./internal/middleware/... -short -p 1 green (EXIT=0, 0 FAIL) against postgres:16 / redis:7 / mongo:6 service containers.

🤖 Generated with Claude Code

Remaining under 95% — residual arms + seam attempted

Four files improved substantially but did not reach 95% on this slice. The
residual uncovered statements are concentrated in arms that need invasive
mid-flow failure injection (not reachable with the brokenDB/sqlmock/dead-Redis
seams used here without a deeper production rewrite). Documented per the
"no waiver without a seam attempt" rule:

• webhook.go (90.3%) — uncovered: the anonymous-provision success error
  arms (finalizeProvision-fail, issueOnboardingJWT-fail,
  createOnboardingEvent-fail at the end of NewWebhook), the auth-path
  CreateResource-fail + finalizeProvision-fail arms, the Receive HMAC-secret
  lookup-error arm, and the Receive json.Marshal-fail arm. Seam tried: sqlmock
  mid-provision — but NewWebhook runs parseProvisionBody → requireName → resolveEnv → checkProvisionLimit → CreateResource → finalizeProvision → issueOnboardingJWT against the same *sql.DB; mocking that exact ordered
  multi-query sequence is brittle (every query string + arg must match) and a
  single mismatch fails the whole flow, so I covered the reachable validation +
  dedup + Receive + ListRequests + storeEncryptedURL arms instead.

• billing.go (93.6%) — uncovered: deep RazorpayWebhook sub-handler arms
  (handleSubscriptionCharged unknown-tier / lower-tier-charge sub-id-update
  failures, handleSubscriptionPaused grace-start-fail, maybeRecoverPaymentGrace
  grace-recover-fail / race-not-flipped) and the ListInvoicesAPI /
  UpdatePaymentMethodAPI circuit-open + success arms. Seam tried: the cov2
  webhook harness covers many charged/failed paths, but the sub-id-update-fail and
  grace-recover-fail arms need a DB that succeeds on the lookup then fails on the
  immediately-following write within one handler — a partial-failure injection the
  live test DB can't produce and full sqlmock of the webhook sequence is infeasibly
  brittle. The portal circuit-open + invoice-list-success arms need a real Razorpay
  client behind an open breaker (no seam to force the breaker open from a test).

• resource.go (92.8%) — uncovered: RotateCredentials rand.Read-fail
  (unreachable — crypto/rand never fails on these platforms), url-parse-fail
  (decrypt succeeds but yields a malformed URL — decrypt-fail fires first), and
  encrypt-fail (would need the same cryptoEncrypt seam pattern but the rotate
  path calls crypto.Encrypt directly); the mongo provider pause/resume +
  rotateMongoPassword arms (need a live MongoDB admin connection with a
  pre-seeded user). The redis provider arm IS now covered (via the live test
  Redis ACL toggle).

• onboarding.go (93.8%) — uncovered: a few Claim resource-transfer
  micro-arms inside the JWT-listed-token loop that overlap with the
  fingerprint loop, the sendClaimVerificationEmail GenerateMagicLinkPlaintext-fail
  arm (unreachable — never fails), and StartLanding/ClaimPreview redirect
  micro-branches. The reachable validation, single-use 409, db-error, account-exists,
  create-failure (sqlmock), and fingerprint-augmentation arms are covered.