fix(server): the mode schema advertises the real board vocabulary

[Joshua-Gilbert]

Problem

create_task.mode and set_task_mode.mode described the board's modes as:

'code' | 'advanced' (adds MCP/Browser) | 'ask' (read-only) | 'orchestrator'

Two things wrong with that, both affecting every agent that reads the tool schema:

• It lists four of eight. plan, review, refactor, and devsecops are all real board slugs with their own routing rules and safety profiles in modes.ts, and none of them appear. A caller has no way to discover from the schema that it can ask for a review.
• The four it does list are the stalest four. On Bob 2.0, code/advanced/orchestrator are not modes Bob has — toBob2Mode remaps all three to agent at dispatch. The schema advertised the one subset that no longer means what it says.

This is also the copy that ships to the marketplace: lhm.plugin.json carries these strings verbatim, so the listing published the same wrong schema.

Change

Both descriptions now name all eight slugs, mark ask/plan/review read-only, and state the two facts a caller cannot infer from a slug:

• code/advanced/orchestrator run as agent on Bob 2.0
• review/refactor/devsecops resolve only where the workspace carries .bob/custom_modes.yaml; elsewhere they downgrade with a warning (2.3.1) rather than hang

Routing itself still points at predict_mode rather than restating the keyword table, so there's one source of truth for how a modeless task gets routed.

No behavior change — these are description strings. The board's accepted vocabulary, MODE_PROFILES, and the router are untouched.

Verification

lhm.plugin.json's two strings were checked byte-for-byte against the built dist/server.js rather than eyeballed, so the marketplace copy cannot drift from the served schema:

create_task    MATCH built server
set_task_mode  MATCH built server
stale 4-mode list left in manifest: false
tools: 23 | manifest version: 2.3.1

Gate green: lint, format:check, 736/736.