test(admin): add negative HTTP-layer tests for registered_clients full-admin gate

[dcadenas]

Summary

PR #168 added admin endpoints for managing registered_clients but only had repo-layer tests.
This change adds HTTP-layer tests so a future refactor cannot quietly drop the full-admin gate.
It covers all five endpoints (list, create, update, delete, pattern tester) for both support-admin and plain-user callers.

Closes #169.

What Changed

New test file api/tests/registered_clients_admin_http_test.rs drives each handler through axum and asserts 403.
The tests reuse the closure-based Router pattern from headless_auth_test.rs: each route is wired with a closure that constructs TenantExtractor and UcanAuth directly, so no global KEYCAST_STATE setup is needed.
The HTTP path stays real — actual axum routing, JSON body parsing, and IntoResponse mapping run during the test.

• 10 negative tests: support-admin and non-admin → 403 on each of the 5 endpoints.
• The create-path tests also check the DB to confirm the gate fires before any insert.
• 2 positive sanity tests on the read paths (list, pattern test) so the negatives are not vacuous.
• Random per-test pubkeys avoid any interaction with ALLOWED_PUBKEYS env var pollution.
• Tenant scoping is intentionally left to the existing repo-layer tests in registered_clients_admin_test.rs, per the issue.

Testing

The full file passes locally and a red/green check confirmed the assertions are real.

• DATABASE_URL=postgres://postgres:password@localhost/keycast_test cargo test -p keycast_api --features integration-tests --test registered_clients_admin_http_test → 12/12 pass.
• Red/green check: temporarily replaced the gate in list_registered_clients with if false { ... }; the two list tests failed with 200 vs 403; restored the gate; all pass again.
• cargo clippy --all-targets --features integration-tests clean.
• cargo fmt --check clean.

Risks

The risk is low because this is test-only and the production gate code is untouched.

• The closures inject UcanAuth instead of running the real extractor, so this does not retest UCAN parsing or DPoP enforcement (already covered by admin_token_test.rs).
• A polluted ALLOWED_PUBKEYS could in theory whitelist a generated pubkey, but matching a 256-bit random hex string by accident is not a real concern.

[NotThatKindOfDrLiz]

Reviewed. I agree with the shape of this PR. This is the right regression lock for the registered_clients full-admin gate: real axum routing, real handler bodies, and the important create-path DB assertion proving the auth check fires before mutation.

I do not see a blocker here. I filed the remaining non-blocking follow-ups separately:

• #182 positive full-admin create/update/delete HTTP tests for symmetry
• #183 DB-state assertions on rejected update/delete paths to mirror the strong create-path check

Approving.