[Channel RFC] Add Nyx-backed Lark provisioning flow with zero local credential persistence

[eanzhao]

Parent: #296

Goal

Build the Aevatar-side provisioning flow for Lark under the Nyx-backed topology, while ensuring Aevatar does not persist Lark credentials or long-lived Nyx credentials for this path.

In Scope

• Accept Lark app_id / app_secret as provisioning input
• Call Nyx to create or update the agent API key with callback_url=/api/webhooks/nyxid-relay
• Call Nyx to register the Lark channel bot
• Call Nyx to create the default route for that bot + agent key
• Persist only non-secret Nyx handles needed later, such as:
  • nyx_channel_bot_id
  • nyx_agent_api_key_id
  • route_id if Aevatar creates and stores it during provisioning
  • status flags / timestamps
• Document the current manual Lark console step: webhook URL still points to Nyx

Constraints

• Do not persist app_id, app_secret, verification_token, encrypt_key, Nyx API keys, Nyx user session tokens, or Nyx refresh tokens in actor state/readmodels/local secret stores for this flow
• Do not assume Nyx callbacks downlink route_id; if Aevatar stores it, treat it as provisioning-time state only

Likely Touchpoints

• agents/Aevatar.GAgents.ChannelRuntime/*registration*
• agents/Aevatar.GAgents.NyxidChat/*
• any Nyx provisioning port / tool / script layer used by channel setup

Acceptance

• Aevatar can provision Nyx agent key + Lark bot + default route from user-supplied app_id / app_secret
• Channel registration state/readmodel persists only non-secret Nyx identifiers and status fields
• The manual Lark console webhook step is documented in code/docs/UI copy where appropriate
• No local persisted credential-bearing fields are introduced for this flow