Add generic agent token binding

[chubes4]

Problem

Agent bearer tokens are a generic runtime-auth primitive, but Data Machine currently owns token management and token-derived authorization.

Any non-Data-Machine agent runtime will need the same mapping from bearer token to agent/user/principal.

Goal

Lift token binding into Agents API so tokens resolve to the same execution principal as WordPress user-session requests.

Current Shape

• Data Machine exposes datamachine agent token management.
• Agent auth callback handling and token-derived access are Data Machine concerns today.
• Chat/session dedupe already has optional token ID vocabulary in the transcript contract.

Scope

• Add an Agents API token binding contract for creating, listing, revoking, and resolving agent runtime tokens.
• Tokens should resolve to an execution principal containing user ID, agent ID, auth source, and token ID.
• Provide a Data Machine-backed implementation using existing token storage.
• Keep Data Machine CLI commands working as compatibility wrappers or product UX over the generic contract.
• Add tests for token creation, revocation, lookup failure, and principal resolution.

Out of Scope

• No OAuth provider changes.
• No Discord/Kimaki-specific logic.
• No external callback protocol redesign.
• No schema migration unless the current storage cannot express the generic contract.

Dependencies

• Depends on execution principal.
• Depends on materialized agent identity.
• Should land after access grants if token resolution must enforce agent access roles.

Acceptance Criteria

• Agents API can resolve a bearer token to a generic execution principal.
• Data Machine token CLI behavior remains unchanged.
• Revoked or unknown tokens fail closed.
• Tests cover token-to-agent and token-to-user binding.
• PR body includes AI assistance disclosure.