sminos bridge: scope the delivery key by project (#229)

[SSFSKIM]

Fixes #229.

The bridge mod deduplicated sminos deliveries with a per-writer seq mark (hooks/mods/bridge.tsx deliver()), but each project numbers a writer's events on its own. A writer that had delivered a higher seq to a session in one project had that writer's messages to the same session in another project, at or below the mark, answered duplicate. sminos_control.deliver then read that as success, and deliver_next settled them. An audit of every addressed message on this machine (283 pairs, matched against the recipients' transcripts) found 13 such losses:

• the 10 reported in sminos bridge drops a writer's messages in a second project as duplicates (per-writer seq watermark ignores the project) #229: doperpowers 1ea561bc:1–10 → CI-opt, bare mark 98;
• 3 more: hub MAWS a45b97a3:8, 10, 13 (sends from CI-opt to maws-3f), bare mark 13 from local-MAWS.

The audit found nothing delivered twice and nothing sent to the wrong session.

Change

• The delivery key carries the project: {project, writer, seq}, from push_event / send / the seat send path through push_member → push_live → sminos_control.deliver.
• The mod's mark is <project>/<writer>. A key with no project (from a CLI older than this) is held to the bare writer mark, the only mark such a CLI ever raised. Kept bare marks are left as they are, so nothing is migrated or dropped, and a poisoned bare mark stops mattering once scoped keys arrive.
• The child (sminos_bridge.py) keeps the same scoped marks. Refusals keep the project in their key. sminos_outcomes.report_refused skips another project's refusal.
• A duplicate answer is no longer silent: sminos_control.deliver warns (the sender's say prints it) and writes a daemon.log line, and still settles, since with scoped keys a duplicate really was submitted before.
• DX5 (docs/doperpowers/plans/2026-10-15-arkho-desk-c2-bridge.md) updated where it defines the kept marks, the deliver key and the delivered event.

Tests

• bridge.test.ts:
  • one writer/seq in two projects is submitted in both;
  • a scoped key below its project's mark is a duplicate;
  • a project-less key is checked against the bare mark;
  • CI-opt's exact case: a kept bare mark of 98, then {project: p2, …, seq: 6} is submitted.
• test-bridge-control.sh, through the real CLI: the second project's lower seq is delivered beside an existing bare mark, and a duplicate warns and logs.
• test_policy_requests.py: a refusal kept by another project is not reported here.
• Each new test fails with its fix reverted.

Review: medium rung, 2 findings, both about version skew, dismissed:

• A new mod with an old child can't happen: the mod starts the child from its own plugin directory ($.plugin.root, bridge.tsx:645).
• An old daemon reading scoped refusals is possible only for the one tick before the daemon restarts on its changed code, only for hub projects, and only for a refusal whose writer/seq repeats in another project.

ci-gate GREEN on 039c10b: https://github.com/SSFSKIM/doperpowers/actions/runs/39097186323.

Version 7.172.0: merge after #228 (7.171.0). A running session keeps its old mod until it restarts or reloads its mods.

🤖 Generated with Claude Code