spike: derive a local GitHub principal from gh login

[quinn-code-agent]

Context

P3.5 accepts a provider-neutral verified-session contract but deliberately does not implement an identity provider, OAuth callback, HTTPS ingress, or shared dogfood deployment.

We need a small, local-only discovery slice to determine how an already-authenticated GitHub CLI session could supply a stable GitHub principal to a future identity broker. This is not a browser login solution.

Goal

Implement a disposable, local-only gh login principal-discovery spike that derives a provider-neutral subject from the active GitHub CLI identity and demonstrates the minimum input needed by the P3.5 proxy-claim contract.

Strict scope

• Read the active gh identity using supported gh commands/API only.
• Use GitHub's immutable numeric user ID to derive github:<numeric-id>; never use login name/email as the stable subject.
• Demonstrate local construction/verification of the existing P3.5 claim shape with temporary non-secret fixtures.
• Document observed scopes and the boundary between local CLI identity and a future browser OAuth broker.

Non-goals

• No browser OAuth, OAuth callback, PKCE implementation, or GitHub token extraction/export.
• No proxy deployment, HTTPS/public ingress, real Relay credentials, or shared dogfood.
• No workflow authority, Resolution authority, GitHub org/team authorization policy, or mapping from GitHub identity to owner role.

Dependencies and follow-ups

• Requires the accepted P3.5 viewer transport contract as its consumer boundary.
• Informs the future GitHub OAuth/PKCE broker design.
• Integrates later with the Relay external verified-identity binding tracker: https://github.com/spacedock-dev/subspace-relay/issues/45.
• It is independent of Relay #42, which is the optional guest device-key route.

Acceptance criteria

• A local test proves stable github:<numeric-id> subject derivation from a fixture equivalent to gh api user output.
• Login names/emails cannot become the stable subject.
• The spike neither reads nor prints access tokens, nor writes credentials to disk.
• It does not start a listener, use a tunnel, or call Relay.
• Documentation explicitly states gh login is developer-local discovery, not browser authentication.
• The result is a small design/evidence note for the future OAuth broker and Relay binding work.

[quinn-code-agent]

Reciprocal relationship note: https://github.com/spacedock-dev/subspace-relay/issues/45 is the provider-neutral external verified-identity binding contract. This issue is only local gh login discovery; it does not implement browser OAuth or create a Relay capability.