feat(feishu): add agent binding workflow

[xxx7xxxx]

Summary

• Add the Feishu agent binding and registration workflow, including local participant-backed binding storage and API endpoints for starting/finalizing registrations.
• Wire Feishu-bound Codex agents through the channel bridge/gateway path so runtime and channel state stay in sync. (NOTICE: Currectly we use picoclaw-manager as a gateway sidebar for codex since there's a lot of resuable code, we should replace it with CSGClaw itself in future cause the heavy trace)
• Add Feishu UI actions, icons, pending-registration polling, and disconnect/finalize controls in the agent/workspace screens.
• Harden docker embed manifest checks so killed checks retry cleanly instead of being treated as out-of-sync refs.

Screenshots

[xxx7xxxx]

Rebased on the local codex bridge.

[RussellLuo]

This new client is not wired into the actual startup path in this PR. The Feishu Codex bridge still uses the existing host-side NewFeishuClient(feishuSvc) from serve.go, so keeping this file here leaves an incomplete parallel path that is easy to mistake for the real implementation. Unless follow-up commits are going to integrate it immediately, it would be better to remove it from this change set.

[xxx7xxxx]

Addressed in 7e2d6b3: removed the unused codexbridge.FeishuHTTPClient path and its dedicated tests. The startup path now only uses the host-side channelbridge.NewFeishuClient(feishuSvc) wiring from serve.go.

[RussellLuo]

I think the current extraction around internal/participant/feishubind is moving in a useful direction, but the layering still feels muddled.

Before this PR, participant bind was effectively a thin CLI-over-HTTP flow:

• the CLI resolved the target agent through the API client,
• created or updated the Feishu participant through the API client,
• and triggered worker recreate through the API client when requested.

This PR removes the duplication from the CLI file, which is good.
But the new shape now makes feishubind sit in an awkward middle layer:

• from the CLI path, it is still driving an apiclient.Client, so it is still orchestrating HTTP/API behavior,
• from the feishu_registration path, it is called directly from the handler through NewLocalClient(...), so it is also acting as a local application-service helper.

That means the same helper now hides two very different execution modes behind one client abstraction:

• remote API transport,
• local in-process service calls.

This is where the structure starts to feel confusing.
internal/participant/feishubind sounds like it should contain the Feishu binding business logic itself, but in practice it now also owns transport-level orchestration concerns.

I think the cleaner direction would be:

• keep internal/participant/feishubind focused on the binding business logic only,
• let feishu_registration call that logic directly in-process,
• and let the CLI continue to use the public API surface instead of introducing a local special case.

In other words, it would be better if the boundary looked like this:

• CLI -> API
• API handler -> binding use case / business logic
• business logic -> participant/agent services

rather than:

• CLI -> API client -> feishubind
• API handler -> local client -> feishubind

The current version works, but it makes feishubind feel neither purely domain logic nor purely API glue, and that ambiguity will probably get harder to maintain as the Feishu setup flow keeps growing.

[xxx7xxxx]

@RussellLuo Addressed in 404a2e1: participant bind is back to owning the CLI-over-public-API orchestration, while feishu_registration now calls the in-process Feishu bind use case directly with agent.Service / participant.Service. Removed NewLocalClient(...) and added boundary tests to keep this layering from regressing.