Security: redact paired API key from Insights log ring buffer

[mimeding]

Summary

Why this matters (business)

Pairing is the moment Osaurus hands a long-lived, master-scoped API key to a trusted device. That key grants the same level of access as the user's primary credential, which is exactly why the UI shows it only once and asks the user to copy it.

Today, the same secret is also being silently saved to the in-app Insights log ring buffer, where it can be read back at any time without any prompt. Screen recordings, screen-sharing during a support call, a future "Export Insights" support-bundle action, or any process that can dump app memory now contains a credential the user thought they only revealed to one peer.

This is a classic "secrets in logs" problem and the kind of audit finding that drags into security reviews. The fix here is cheap and behavior-preserving.

What's wrong (technical)

handlePairEndpoint builds a PairResponse on success, writes it to the wire, and also passes the same JSON string to the Insights logger:

            // 5. Return the agent's address, the generated API key, and the permanence flag.
            let response = PairResponse(agentAddress: agentAddress, apiKey: fullKey, isPermanent: isPermanent)
            let json =
                (try? JSONEncoder().encode(response)).map { String(decoding: $0, as: UTF8.self) }
                ?? #"{"error":"Encoding failed"}"#

            hop {
                ...
                logSelf.logRequest(
                    method: "POST",
                    path: "/pair",
                    ...
                    responseBody: json,
                    responseStatus: 200,
                    ...
                )
            }

InsightsService keeps a 500-entry in-memory ring buffer that is bound to a SwiftUI list. So the full osk-v1-... value is:

• visible inside the running app on the Insights tab,
• searchable via the in-app search box,
• captured in any screen recording / shoulder-surfing,
• present in any future log export feature,
• recoverable from a memory dump.

The connector still receives the real key on the wire; this is the only code path that copies it elsewhere.

Fix

Build a second, redacted PairResponse exclusively for the Insights call. The apiKey field becomes the clearly-marked placeholder string osk-v1-***REDACTED***. The wire response is byte-identical to before — pairing continues to work end-to-end.

Out of scope (intentional, can be follow-ups):

• General secret-scrubbing for any other endpoint that might echo Authorization headers.
• Pairing-side hardening (rate limits on /pair, agent-scoped key by default, replay-nonce store). Those are larger threat-model changes; this PR is purely the leak fix.

Changes

• Behavior change (Insights only — wire response unchanged)
• UI change
• Refactor / chore
• Tests (no existing test fixture for Insights ↔ HTTP handler integration; the change is small enough to verify manually)
• Docs

Test Plan

1. Run the app, enable Bonjour, pair a new connector.
2. Open the Insights tab and locate the POST /pair row.
3. Before this change: the responseBody column contains the full osk-v1-... key.
4. After this change: the responseBody column shows "apiKey":"osk-v1-***REDACTED***" while the paired connector continues to authenticate successfully (proving the wire body is untouched).

Checklist

• I have read CONTRIBUTING.md
• I added/updated tests where reasonable (see "out of scope" above)
• I updated docs/README as needed (n/a — internal observability only)
• I verified build on macOS with Xcode 16.4+ (authored in a Linux CI sandbox)