Feishu bot: make the approval integration first-class and document how to connect it

[Daily-AC]

What exists

The portal can push approval and pairing requests to a Feishu (Lark) 1:1 chat as interactive cards and take the owner's allow/deny from the card over the SDK's long connection (internal/lark, internal/portal/larkwatch.go). The Docker image is built with -tags lark, and the portal turns it on when WANCTL_LARK_APP_ID and WANCTL_LARK_APP_SECRET are set. Cards are addressed by the portal user's email (receive_id_type=email).

What a self-hoster sees today is one sentence in docs/environment.md calling it a "legacy optional Lark approval integration" and a startup log line lark approval disabled. Nobody can get from there to a working bot without reading the code.

What this issue asks for

1. A guide, docs/feishu-bot.md (+ .zh.md), that gets a developer from zero to a working bot. It has to cover the things the Feishu console makes you decide, in the order the console asks:

• Create a custom app in the Feishu developer console; where the App ID and App Secret are.
• Enable the bot capability.
• Permissions (scopes) the app must be granted, listed exactly as the console names them: sending messages as the bot, sending interactive cards, updating a card it sent, and resolving a user by email (receive_id_type=email needs the contact scope for that). Verify the list against a fresh app, not from memory.
• Event subscription: use the long connection mode (no public callback URL needed), and subscribe to the card action callback (card.action.trigger). Say explicitly that no webhook URL or encrypt key is required in this mode.
• Publish the app version so the permissions take effect, and add the bot to the owner's visible range.
• The portal side: the two env vars, what the startup log line looks like when it is on, and how the portal user's email must match the Feishu account (the email on the GitHub identity used to sign in to the portal).
• How to verify: the existing live probe (WANCTL_LARK_TEST_EMAIL / WANCTL_LARK_LIVE_SECONDS, see internal/lark/live_consumer_test.go) or a manual pairing request, and what a healthy card looks like.
• Common failures mapped to their cause: card never arrives (missing scope / bot not visible to the user / email mismatch), card arrives but the tap does nothing (event not subscribed / app version not published), lark approval disabled (secret unset).

2. Make it first-class in the product surface.

• Drop the "legacy" wording in docs/environment.md and link the guide from docs/self-hosting.md (the section that currently explains away the lark approval disabled log line).
• selfhost/ compose: the two env vars present and commented out, pointing at the guide.
• The portal's per-device Feishu card (rendered when /api/me reports lark: true) should say, when it is off, where to turn it on, instead of hiding silently.

Acceptance

• A person who has never used the Feishu developer console follows the guide on a fresh app and receives a working approval card, tap included, without reading Go code. Record which console screens differ from the guide and fix the guide.
• The scope list in the guide is the minimal set: remove one and the probe fails.
• Docs parity check (tools/docsite/build.py) passes.

Not in scope

No plugin system, no build-tag rework, no new config keys beyond the two that exist (#13 was closed in favour of this).

[Daily-AC]

One constraint the guide has to solve, from the 2026-09-05 migration notes: the existing code addresses cards with receive_id_type=email and takes the email from the portal identity. On this instance the identity is a GitHub login, not an email, so the current mapping does not work here at all. The integration needs an explicit per-user (or per-device) Feishu recipient setting in the portal — email or open_id — rather than assuming identity == email. That is the one piece of product surface this issue adds beyond documentation.

Also worth folding in: the 2026-09-05 direction was that the relay's existing webhook notifications (v0.4.0) should eventually carry approval actions, and that users should be able to connect their own bot. This issue is that second half; the guide should be written for a user who creates their own Feishu app, not for the operator.