docs(feishu-bridge): separate this Plugin from the built-in Feishu support

## Problem

The title says "drive MiniMax Code from a Lark/Feishu conversation", and MiniMax
Code already ships two things that answer to the name Feishu. A reader landing on
this PR, and a reviewer triaging it, both have to work out on their own whether
this is a duplicate. That answer belongs on the page, not in a discussion thread.

The two existing pieces, and what each one actually does:

- `lark-tools`, the built-in Skill: mcode -> Feishu. Office work, reading and
  writing documents, calendar, Base, mail, approvals. It does not run a task on
  the user's machine.
- The Feishu channel in the desktop runtime, under packages/local-runtime/src/
  channels/: Feishu -> agent. The same direction as this Plugin, but it needs the
  Mavis desktop app running and a Feishu app bound to it, and it answers with
  interactive cards, including a permission card that approves a pending tool call
  by tapping.

Neither one is this Plugin, and none of the three replaces another. Saying so was
missing, not because it was contentious but because nothing on the page drew the
line.

## Changes

The README gains a section, "How this differs from the built-in Feishu support",
directly after "What you get". It carries a three-row table of the three
implementations and their directions, what each is for, why the built-in channel
is the better choice for someone already working in the desktop app, and the case
this Plugin covers instead: a headless machine with mcode and lark-cli on PATH and
nothing else.

It also states the cost rather than only the benefit. This Plugin edits plain text
messages instead of sending cards, and it runs with `--permission full` because
there is no in-chat prompt to tap, linked to the Security model section that
already explains what that exposure means.

Both SKILL.md copies gain the same distinction as a blockquote at the top of
"Before starting anything", so the agent reads it before setting a bridge up
rather than after a user reports that the official Skill already does this. It
carries the instruction not to present this Plugin as a replacement for
`lark-tools`.

## Validation

    node scripts/validate.mjs
    -> Validated 29 hosted Plugins and all examples.

    node scripts/mcode-feishu-bridge.test.mjs
    -> 84 passed, 0 failed, 0 skipped

Both match the previous commit's baseline, which is what a documentation change
should produce.

## Test evidence

There is no new runtime behaviour to break, so the checks that matter here are the
ones that could have silently falsified a claim the Plugin makes about its own
packaging:

- Both SKILL.md copies are still byte-identical. Each file was edited separately
  and the comparison is by hash afterwards, so the check does not pass merely
  because one file was copied over the other:
  9D58DA024923420C0ED515F4B57A7F2BFE6B5E65FE226441C163BB6EADB33A87 for both.
- All three edited files are still LF with no BOM, matching the Plugin-local
  .gitattributes, verified at byte level rather than by eye.
- The `#security-model` anchor the new section links to resolves; "Security
  model" is a real heading in this README, not an aspirational one.

## Design compliance

- Documentation only. No code, manifest, or test file is touched: 47 inserted
  lines across three files, zero deletions.
- Both runtime layouts still ship byte-identical Skill copies.
- No claim about the official implementations goes beyond what is observable: the
  Skill list as the product's own plugin panel enumerates it, and the direction
  and host implied by the file names under packages/local-runtime/src/channels/.
- No credentials, endpoints, or host paths introduced.

Author: antianqi

plugins/antianqi/mcode-feishu-bridge/README.md

@@ -69,6 +69,37 @@ conversation stays readable and nothing is duplicated.
 - **Readable while running.** The log is written by the bridge itself, so you can
   read it without the file being locked.
 
+## How this differs from the built-in Feishu support
+
+MiniMax Code ships Feishu support in two places already, and neither one is this
+Plugin. This one sends messages in the opposite direction, against a local mcode
+CLI rather than the desktop runtime.
+
+| | direction | what it is for |
+|---|---|---|
+| `lark-tools` (built-in Skill) | mcode → Feishu | office work: read and write docs, calendar, Base, mail, approvals |
+| Feishu channel (local-runtime) | Feishu → agent | driving the Mavis desktop runtime through a bound Feishu app |
+| **This Plugin** | **Feishu → mcode** | **driving a local mcode CLI install** |
+
+The first is not a remote control. Ask it to summarise this week's meeting notes
+and it does that inside Feishu; it does not run a task on your machine.
+
+The second has the same shape as this Plugin but a different host. It lives in the
+Mavis desktop runtime, so it needs the desktop app running and a Feishu app bound
+to it, and it answers with interactive cards — including a permission card that
+approves a pending tool call by tapping. Prefer it if the desktop app is already
+your working environment.
+
+This Plugin covers the remaining case: a headless machine with `mcode` and
+`lark-cli` on `PATH` and nothing else. It is a plain polling process, so any
+supervisor you already use can restart it, and there is nothing to install. In
+exchange it edits plain text messages instead of sending cards, and it runs with
+`--permission full` because there is no in-chat approval prompt to tap — see
+[Security model](#security-model).
+
+The two do not conflict. Installing this Plugin neither requires nor disables the
+built-in channel, and both can run at once.
+
 ## Setup
 
 The Plugin is Skill-only: no `mcp.json`, no `package.json`, no install step. But it

plugins/antianqi/mcode-feishu-bridge/skills/SKILL.md

@@ -21,6 +21,14 @@ twelve tool calls still produces one bubble, not twelve.
 
 ## Before starting anything
 
+> **Do not confuse this with the built-in `lark-tools` Skill.** `lark-tools` drives
+> Feishu *from* mcode — documents, calendar, Base, mail, approvals. This Plugin is
+> the opposite direction: a Feishu message becomes a local `mcode` turn. The
+> desktop runtime also has a Feishu channel, which is the same reverse direction but
+> needs the Mavis desktop app running and a Feishu app bound to it. Never present
+> this Plugin as a replacement for `lark-tools`; they do different jobs and can run
+> side by side.
+
 The bridge has **no credentials of its own**. It uses `lark-cli`, which must already
 be configured for the user. Check first:
 

plugins/antianqi/mcode-feishu-bridge/skills/mcode-feishu-bridge/SKILL.md

@@ -21,6 +21,14 @@ twelve tool calls still produces one bubble, not twelve.
 
 ## Before starting anything
 
+> **Do not confuse this with the built-in `lark-tools` Skill.** `lark-tools` drives
+> Feishu *from* mcode — documents, calendar, Base, mail, approvals. This Plugin is
+> the opposite direction: a Feishu message becomes a local `mcode` turn. The
+> desktop runtime also has a Feishu channel, which is the same reverse direction but
+> needs the Mavis desktop app running and a Feishu app bound to it. Never present
+> this Plugin as a replacement for `lark-tools`; they do different jobs and can run
+> side by side.
+
 The bridge has **no credentials of its own**. It uses `lark-cli`, which must already
 be configured for the user. Check first: