feat(rpc): allow admin-issued preload UCANs to sign for claimed users

[rabble]

Summary

• Drop the is_unclaimed gate in load_preloaded_user_handler (api/src/api/http/nostr_rpc.rs) so admin-issued preload UCANs continue to work after a user claims their account.
• Existence check preserved — non-existent users still rejected with InvalidToken.
• Updated docstrings on load_preloaded_user_handler and the MODE 2 branch in get_handler to reflect the new behavior.

Why

We've discovered more classic Vine archives belonging to accounts that users have already claimed, and users want them published under their accounts. The mint side (/api/admin/preload-user) was already idempotent on vine_id and happily returned a fresh signing UCAN regardless of claim status; the signing endpoint at nostr_rpc.rs was the sole remaining block.

Behavior change

Before: a server-signed preload UCAN could only sign for users where email IS NULL. Once a user claimed, their preload UCANs became dead.

After: the same preload UCAN works for both unclaimed and claimed users, until the UCAN itself expires (30 days) or gets evicted from cache.

The mint gate is unchanged: only is_full_admin callers can mint these UCANs, so the externally-reachable attack surface is the same.

What this expands

A leaked admin token can now sign as any user (claimed or not) for as long as a 30-day preload UCAN lives. Before, claim was a user-side seal that closed that door. Acceptable for our small ops team and the Vine republish workflow, but the threat model genuinely changed.

Follow-ups (not in this PR)

• Add audit trail for admin-issued preload UCAN signing operations #231 — add per-sign audit trail to admin_audit_events so we can answer "who signed what as whom" months after the fact. Schema + insertion-site notes are in the issue.
• Consider shortening preload UCAN TTL from 30d → 24h to cut the leaked-token window.
• get_user_token (pubkey-based admin endpoint at admin.rs:344-393) still has its own is_unclaimed block. Inconsistent with the new vine_id behavior, but the import script doesn't use that path so it's not blocking. Worth aligning later.

Test plan

• Build passes (cargo build -p keycast_api)
• Existing admin_preload_test, admin_token_test, admin_batch_claim_test still pass (they test mint-side and is_unclaimed repository behavior, both unchanged)
• Manual: in staging, mint a preload UCAN for a claimed test account, hit /api/nostr with sign_event, verify it returns a signed event instead of InvalidToken
• Manual: confirm preload UCAN for nonexistent pubkey still returns InvalidToken

🤖 Generated with Claude Code

[irab]

Looks fine - definitely would be good to change that expiry from 30D to however long the import script normally takes to run. I assume 1-4hrs?

[dcadenas]

The new preload signing path needs tighter auth checks before this can merge.
It must only accept real preload UCANs, and cached preload handlers must stop at the UCAN expiry.

The PR description bounds the leaked-token window at 30 days. With the cache-expiry issue below, a warm cache pushes that to effectively unbounded, so the stated tradeoff doesn't hold yet.

---

Additional findings not shown inline

• Carry UCAN expiry into cached preload handlers
  

  keycast/api/src/api/http/nostr_rpc.rs

  Line 453 in dd4d4e4

  None, // No expiry (handled by token expiry)

  
  Carry the UCAN expiry into cached preload handlers.
  This path caches preload handlers with expires_at: None, so after the first valid use, later cache hits return the handler without revalidating the UCAN.
  The cache uses time_to_idle(3600), which resets on every access, so a token hit at least once per hour never evicts. A warm cache entry can keep signing past the 30-day UCAN lifetime until process restart, effectively unbounded for continuously-used tokens.
  Store the UCAN expiration on the handler or cache entry, and add a test that a warm cache rejects the token after expiry.

[dcadenas]

Restrict this branch to real preload UCANs before loading personal keys.
Right now any server-signed UCAN without bunker_pubkey reaches load_preloaded_user_handler. That means claim-session tokens, or the admin UCAN returned by GET /api/admin/token, can become full-access RPC signing tokens for whoever the UCAN's audience is, provided personal_keys exists for them.
Require preload-specific facts, such as redirect_origin == "preload" and issued_by_admin, or add a dedicated token-purpose fact before this path loads the handler.
Add tests that accept an admin preload UCAN for a claimed user and reject claim/admin server-signed no-bunker tokens.

[rabble]

@dcadenas Both findings addressed in df843b9:

1. Real preload UCANs only — load_preloaded_user_handler now takes the UCAN's redirect_origin as a parameter and rejects anything that isn't "preload". Server-signed admin-session UCANs and claim UCANs can no longer fall through MODE 2 to sign as users.

2. UCAN expiry carried into cached handler — get_handler now extracts ucan.expires_at() and threads it into HttpRpcHandler::new instead of passing None. The cache hit path's handler.is_valid() check will now return false once the UCAN lifetime ends, so warm cache entries can't keep signing past exp.

Tests added (api/tests/nostr_rpc_integration_test.rs):

• test_warm_cache_preload_handler_rejected_after_ucan_expiry — exactly what you asked for. Mints a preload UCAN with lifetime: 2s, exercises a successful sign to populate the cache, sleeps 3s past expiry, then asserts the second call (cache hit) returns InvalidToken and the cache entry is evicted.
• test_server_signed_non_preload_redirect_origin_rejected — mints a server-signed UCAN with redirect_origin: "admin" and verifies the signing path rejects it before touching the user's key.

Both new tests pass. The 6 pre-existing tests in this file still pass, as do the adjacent admin_preload_test, admin_token_test, and admin_batch_claim_test suites.

[dcadenas]

🔑 claimed-user preload signing lands cleanly