fix: monorepo release tags omit plugin features shipped on npm — release-train mapping undocumented

[kiwipaulrob]

Pre-submission checklist | 提交前检查

• I have searched existing issues and this hasn't been mentioned before | 我已搜索现有问题，确认此问题尚未被提及
• I have read the project documentation and confirmed this issue doesn't already exist | 我已阅读项目文档并确认此问题尚未存在
• This issue is specific to MemOS and not a general software issue | 该问题是针对 MemOS 的，而不是一般软件问题

Bug Description | 问题描述

The monorepo product release tags and the npm plugin releases appear to have diverged in content, and there is no documented mapping between the two version trains — which makes it hard for users and tooling to tell which release is current.

Concretely, the plugin's shared-bridge runtime (apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py) — the fix that lets multiple Hermes sessions share one bridge process instead of fighting over them — landed on main on 2026-07-29 (commit 92653cd8, "Release/memos local plugin v2.0.12 beta.1 (#2184)") and is present in the npm releases 2.0.12 → 2.0.14 (current latest). However, the monorepo product tags v2.0.24, v2.0.25 and v2.0.27 do not contain this file, even though v2.0.27 was released on 2026-07-31 — two days after the change landed on main.

The result is the mirror image of #1854 (where npm lagged GitHub): the npm train is now functionally ahead of the monorepo tag train, while the version numbers say the opposite. A user running a monorepo-era build ("2.0.24") is numerically newer than npm 2.0.14, so a naive version comparison (e.g. a no-downgrade guard) refuses the npm package — silently blocking access to the shared-bridge fix. "Which version am I on, and is it current?" is genuinely unanswerable today.

How to Reproduce | 如何重现

1. Confirm the shared runtime exists on main and in the npm release train tags:

curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/main/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py            # 200
curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/memos-local-plugin-v2.0.12/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py # 200
curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/memos-local-plugin-v2.0.14/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py # 200

2. Confirm the same file is missing from the monorepo product tags:

curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/v2.0.24/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py # 404
curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/v2.0.25/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py # 404
curl -fsSL -o /dev/null -w "%{http_code}\n" https://raw.githubusercontent.com/MemTensor/MemOS/v2.0.27/apps/memos-local-plugin/adapters/hermes/memos_provider/shared_bridge_runtime.py # 404

3. Observe: two version trains on the same repository, with no published mapping, and the "higher" monorepo number being functionally older than the "lower" npm number.

Environment | 环境信息

• Host: Hermes Agent v0.20.0 on Debian 12 LXC
• Plugin: @memtensor/memos-local-plugin build "2.0.24-restored" (monorepo v2.0.24-era build with local patches)
• npm latest: 2.0.14 (published 2026-08-07)

Additional Context | 其他信息

• Precedent: memos-local-plugin v2.0.17 release not published to npm; latest remains 2.0.5 #1854 ("memos-local-plugin v2.0.17 release not published to npm; latest remains 2.0.5") covered the first half of this — npm lagging GitHub — and was resolved by establishing the npm publication cadence. This issue is the other half: the npm cadence is now ahead of the monorepo product tags.
• Impact beyond version confusion: users building from the monorepo train miss the shared-bridge runtime entirely, and numeric comparison (2.0.24 > 2.0.14) actively blocks adopting it from npm.
• Possible directions (very open to maintainer preference): (a) document a mapping between monorepo release tags and plugin npm versions — e.g. a short matrix in each release note/discussion or a RELEASES.md; (b) ensure each plugin npm release is also reflected in a monorepo tag cut from the same commit; (c) anything else the team prefers.
• Happy to help draft the release-matrix note or a tracking doc if useful — no urgency.

Willingness to Implement | 实现意愿

• I'm willing to implement this myself | 我愿意自己解决
• I would like someone else to implement this | 我希望其他人来解决