chore(plugin-catalog): bump composer-modes to 2.0.1 (staging fix)

[LisandroNahuelH]

What does this PR do?

Bumps the composer-modes catalog pin from 4f4e1c0b36165d84a9e2db7c71516f5a0c627d72 to
de372aa34ecfe6adb424f86c04ca2de924984cb0 (plugin v2.0.1). Rule 4 of the catalog README:
a SHA bump is its own PR, and the diff is the review surface — one line, old SHA → new SHA.

The adopted range 4f4e1c0b..de372aa3 is three commits in the plugin repo:

commit	what
1fd6bf5	fix(desktop): stage the mode against the stored session id — the fix, plus its regression test
2520d32	chore(release): 2.0.1 — the five version references together + CHANGELOG
de372aa	docs: record the staging identity contract and the probe that exposes it

What was broken. The desktop half staged the mode against
host.state.focusedSessionId, which the desktop SDK binds to $focusedRuntimeId — the runtime
tile id (short, e.g. a4b090e3). The core fires pre_llm_call with the stored session id
(agent.session_id, e.g. 20260916_192252_7a3c66). The store lookup therefore never matched,
store.get_mode() answered with the default (agent), note_for('agent') is empty by design,
and no mode note ever reached a turn: every turn ran unframed while the button showed
ask/plan/debug. The failure was silent — from inside a turn, "Agent" and "a lost note" are
indistinguishable.

The fix. One helper (backendSid()) resolves host.state.focusedStoredSessionId first and
falls back to the runtime id for shells that do not expose it; stageMode() and the
session-change reset both go through it, and the boot caps probe now prints both ids so a wrong
staging identity is visible in logs/desktop.log instead of invisible.

Catalog-visible surface: unchanged. Same hooks (pre_llm_call, pre_tool_call), same
middleware declarations, no tools, no env vars, no config schema, no self-updating code. The
entry's sha line is the only edit in this PR.

Related Issue

No issue: this is a SHA-bump PR under rule 4. Related, and unaffected by this bump:

• chore(plugin-catalog): add composer-modes #113242 (merged) — the catalog entry this PR updates.
• feat: per-turn model note + display-only mode label on prompt.submit / steer / redirect #108241 (open) — the core seam that would let a plugin place the note before the user text
  (and freeze it per queued message); this package still does not depend on it — it uses the
  supported pre_llm_call path, append-only.
• feat(gateway,desktop): per-turn model note + display-only mode label (composer-mode frame) #108242 (closed) — the earlier reference implementation of that seam.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• plugin-catalog/composer-modes.yaml — sha: 4f4e1c0b… → de372aa3…. No other field, no
  other file.

How to Test

1. Structural gate (what plugin-catalog-ci.yml runs), against a directory holding the
   bumped entry: python scripts/validate_plugin_catalog.py <dir> → OK: 1 file(s) valid.
2. Catalog loader tests in this repo: pytest tests/hermes_cli/test_plugin_catalog.py -q →
   5 passed.
3. Pinned-source gates at the new sha (run in the plugin repo):
   hermes plugins validate . → Validation passed. (manifest, requires_hermes, and the
   capability probe comparing register() against the declared hooks/middleware);
   python -m pytest -c tests/pytest.ini → 103 passed;
   node --check desktop/plugin.js → OK;
   node scripts/smoke_desktop_half.mjs → SMOKE PASSED, and red before the fix
   (staged "sess-runtime" — must stage the stored session id).
4. Live behaviour on Hermes 0.21.3 / Windows 11 with the fix deployed: the desktop half
   hot-reloaded (register ver=v13.1), the stage now carries the stored id
   (stage ok mode=ask sid=20260916_192252_7a3c66), and reading content vs api_content
   back out of state.db shows the note arriving for ask/plan/debug while content stays
   byte-for-byte what was typed, and agent stays unframed.
5. Install path: hermes plugins update composer-modes (or a fresh install) checks out the
   new pin.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate (no other composer-modes bump; the merged chore(plugin-catalog): add composer-modes #113242 is the entry being updated)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — N/A: this PR changes no Python in this repository. The gates that apply are the catalog validator + loader tests (step 1–2) and the pinned plugin's own suite (step 3).
• I've added tests for my changes — N/A for a SHA bump; the plugin repo ships the regression test that pins this fix (red before, green after: node scripts/smoke_desktop_half.mjs)
• I've tested on my platform: Windows 11 (Hermes 0.21.3)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A: updated inside the pinned range (docs/architecture.md, docs/verification.md, CHANGELOG.md under 2.0.1)
• I've updated cli-config.yaml.example if I added/changed config keys — N/A: no config keys
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A: no change in this repository
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — the bump touches one session-id resolution helper in plain-JS ESM with no platform branches; the package declares all three platforms