fix: bunker pair-cap bypass + in-sheet cap gate (sprint 5a)

[DocNR]

Summary

Closes the bunker pair-cap bypass confirmed in build-63 device testing — user reached 7 successful bunker pairs on a single signer when the documented per-signer cap is 5. Sprint 5a from ~/hq/clave/BACKLOG.md ConnectedClient identity sprint.

• 5a-core (NSE row creation): Shared/LightSigner.swift:209 now calls SharedStorage.setClientRelayUrls(...) immediately after saveClientPermissions(perms) in the bunker first-connect handler. Pre-fix, the ConnectedClient row was created lazily by SharedStorage.updateClient only when the first signing request arrived — multiple bunker pairs could land between connect and first-sign without any of them counting toward the cap. Mirrors the nostrconnect path's row-creation timing. Side benefit: closes the L1 relay-set incompleteness noted in BACKLOG sprint 5a (bunker pairs now contribute to L1's foreground subscription set).
• 5a-ux (in-sheet cap gate): ConnectBunkerTabView now intercepts the "New Secret" tap when count >= 5, shows Connection limit reached alert, does not rotate. HomeView's existing entry-point gate (handlePairNewConnectionTap) blocks the sheet from opening at cap; this in-sheet gate covers the case where the user enters under cap and rotates past it during a single session. Copy URI stays enabled so paired clients can re-share for re-pair recovery.

Pre-fix evidence

• Field test (build 63, 2026-05-08): user tapped "Connect Client" + "New Secret" repeatedly on a single signer, reached 7 successful bunker pairs. Documented cap is 5.
• Proxy clients.json snapshot (~/hq/clave/troubleshooting/2026-05-08-clients-json-pre.json): 26 (signer, client) pairs across 15 distinct signers; highest per-signer count is 4. The bypass-test signer is absent from the dump — confirms bunker pairs leave no proxy-side trace (only nostrconnect goes through /pair-client). iOS is the sole enforcement layer for bunker.
• Code review: LightSigner.swift:175-209 reads getConnectedClients(for:).count for the cap-check, but the post-connect side-effect at line 209 saves ClientPermissions only — never ConnectedClient. SharedStorage.updateClient lazily creates the row at first signing request; for clients that haven't signed yet, the count stays stale.

Test plan

• Fresh install (or wipe one signer's pairs) on iPhone with build 69
• Generate 5 successive bunker pairs (each via tapping "New Secret" + scanning into a different client) — all 5 succeed, all visible in Connected Clients list
• Entry-point gate: dismiss ConnectSheet → tap "Connect a Client" on Home → "Connection limit reached" alert fires; sheet does NOT open
• In-sheet gate: open ConnectSheet from a state where count < 5 (e.g. unpair one first, sheet opens), then trigger pairs to 5 from inside — tap "New Secret" → alert fires; secret does NOT rotate
• NSE-side enforcement (defense-in-depth): if both UI gates somehow bypassed (external bunker URI flow), connect attempt chore: bump pbxproj to build 18 #6 → client receives "Pairing limit reached. Unpair an existing client in Clave settings." error
• Capture Recent Logs (Settings → tap Version 7×) — entry should include Bunker connect rejected: pairing cap reached. Save to ~/hq/clave/troubleshooting/2026-05-08-bunker-cap-bypass-post.log.
• Unpair one client → both gates clear → next pair succeeds
• Verify xcodebuild test passes (already green locally; confirm in CI if any)

Tests added

ClaveTests/LightSignerBunkerConnectTests.swift — 4 tests covering:

1. Bunker pair creates ConnectedClient row with relayUrls.contains(SharedConstants.relayURL)
2. Cap-check blocks at 5 existing rows
3. Repeat-pair of same (signer, client) doesn't double-count
4. Per-signer scoping doesn't leak count across signers

Unblocks

Premium-tier entitlement plan — caps now count correctly across both flows, so tier-aware multipliers (free 5 → premium 30 clients/signer) inherit clean counters.

Out of scope (defer)

• 5b (kind:0 client-identity lookup) — open design questions per BACKLOG
• 5c (extractConnectName populate) — cheap, additive; spawn separately if a signer is observed passing name in connect params

Post-fix evidence

Captured 2026-05-09 01:27–01:28 UTC on build 69, real device. Full log: 2026-05-08-bunker-cap-bypass-post.log (saved to ~/hq/clave/troubleshooting/).

Smoking gun: 5a-core row creation at first-connect

01:28:18.649 [LightSigner] Method: connect id=fbr7of-1
01:28:18.652 [Storage] saveClientPermissions: signer=0066778e client=1b571115 trust=medium
01:28:18.653 [Storage] setClientRelayUrls (new client): 1b571115 signer=0066778e count=1
01:28:18.653 [LightSigner] New client paired with valid secret (row created, relay=wss://relay.powr.build)
01:28:18.654 [Storage] save OK: bunkerSecrets (1327 bytes)

Pre-fix: only the saveClientPermissions line would appear; the setClientRelayUrls (new client) row creation was deferred to first signing request. Now both happen atomically at handshake — the count getConnectedClients(for:) returns is authoritative at the time of the next bunker connect's cap-check.

Unpair → re-pair works (regression check)

01:27:53.192 [Pair] unpair-client begin client=5aa9faf1 signer=0066778e
01:27:53.205 [Storage] removeClientPermissions: signer=0066778e client=5aa9faf1
01:27:53.238 [fg-sub] refreshRelaySet: stop+restart
01:27:53.314 [Pair] unpair-client ok client=5aa9faf1 signer=0066778e
[…fg-sub re-establishes subscriptions to the post-unpair relay set…]
01:28:18.649 [LightSigner] Method: connect id=fbr7of-1 ← fresh pair lands cleanly

L1's refreshRelaySet fires correctly after unpair, confirming the relay-set computation observes ConnectedClient mutations.

Existing-client signing path unaffected (regression check)

01:28:19.475 [LightSigner] Method: get_public_key id=fbr7of-2
01:28:19.835 [LightRelay] Published event
01:28:19.934 [LightRelay] OK: true
01:28:19.934 [LightSigner] Response published successfully

get_public_key after the new pair signs and publishes successfully — the !isExistingClient branch where the new setClientRelayUrls call lives doesn't interfere with the existing-client path.

Cap rejection (defense-in-depth, NSE-side)

The 6th-attempt log line (Bunker connect rejected: pairing cap reached (5)) wasn't captured in this window, but the device-test confirmed the behavior: the 6th client received the "Pairing limit reached. Unpair an existing client in Clave settings." error in its UI on attempt. The rejection path is also covered by the unit test testBunkerConnect_capCheckBlocksAtFiveExistingRows.