v0.1: Rename JWT auth token to avoid misleading terminology

[hanwencheng]

Summary

The Heima TEE worker issues JWT-format auth tokens (tee-worker/omni-executor/core/src/auth/auth_token.rs), but calling them "JWT" in AgentKeys documentation and code is misleading. "JWT" implies short-lived, stateless, disposable tokens — but AgentKeys uses these as long-lived (30-day) bearer credentials that warrant high-security storage (OS keychain, memfd_secret, zeroize).

The term "JWT" causes reviewers and contributors to underestimate the security requirements for token storage and memory hygiene.

Proposal

Rename across AgentKeys codebase and documentation:

• "JWT auth token" → "session token" or "auth bearer token" or "TEE-issued bearer"
• The underlying format can stay JWT (signed, stateless verification) — only the user-facing name changes
• Heima-side rename is tracked separately (coordinate with Kai)

What needs to change

AgentKeys side (our repo)

• Wiki docs: wiki/blockchain-tee-architecture.md, wiki/key-security.md, wiki/serve-and-audit.md — replace "JWT" terminology
• Spec docs: docs/spec/1-step-analysis.md, docs/spec/tech-brief.md — update correction notes
• Code: Session.token field naming is already generic (good); any future JWT-specific code should use the new term
• GitHub issues Stage 8: Production hardening — daemon memory hygiene + CLI defensive features #3, v0.1: TEE-side per-session read rate limit (abuse defense) #4, v0.1: Pattern 4 audit submission — TEE-as-paymaster per-read sponsored audit #5, v0.1: Hybrid on-chain pair transport (replaces rendezvous relay + auth_requests table) #6 — update references in issue bodies if needed

Heima side (coordinate with Kai)

• tee-worker/omni-executor/core/src/auth/auth_token.rs — rename AuthTokenClaims and related types
• tee-worker/omni-executor/rpc-server/src/auth_token_key_store.rs — rename key store
• Client SDK: request_auth_token.request.ts — rename request function
• This is a Heima-wide change and may affect other products (PumpX, Wildmeta) — needs coordination

Why this matters

A 30-day bearer credential that grants TEE access to read all scoped credentials is a high-security item. Calling it "JWT" leads to:

• "JWTs are stateless and disposable, so we don't need memfd_secret" — wrong for 30-day tokens
• "JWTs don't need keychain, a plain file is fine" — wrong for high-value bearers
• "JWT leak is bounded by TTL" — technically true, but 30 days is not "bounded" in any practical sense

The rename makes the security posture obvious from the name itself.

References

• wiki/blockchain-tee-architecture.md Section 4, 6 — JWT model documentation
• wiki/key-security.md Section 2 — auth token storage recommendations
• Heima source: tee-worker/omni-executor/core/src/auth/auth_token.rs