Design StarRouter stabilization and StarIntel bridge

[lost-rob0t]

What changed

Adds a research/design baseline for stabilizing StarRouter and building a durable StarRouter → StarIntel Server bridge.

The new docs/design/ set covers:

• full current-state source/code/CI/operations audit
• explicit delivery semantics and a canonical internal protocol envelope
• StarIntel bridge architecture and event mapping
• durable outbox, replay, deduplication, publisher-confirm recovery
• deterministic tests, fuzz/chaos tests, soak tests, and benchmark methodology
• metrics, health/readiness, supervision, runbooks, and unattended operation
• throughput/backpressure/HWM/in-flight-confirm design
• security hardening, SC01 compatibility, and staged migration slices

Why

The current broker is explicitly documented as pre-alpha and the source audit found correctness issues that should be contained before a StarIntel bridge is allowed to amplify traffic. Major verified findings include duplicate dispatch/ACK behavior in handleMessage, Client.newMessage not assigning the requested event type, and target routing mutating newMsg but publishing msg.

The bridge design uses StarIntel's documented RabbitMQ documents exchange as the native destination. It targets at-least-once durable forwarding with idempotent downstream effects, a local durable outbox, mandatory routing, and Rabbit publisher confirms rather than treating ZeroMQ PUB/SUB or an HTTP 2xx as proof of durable persistence.

Developer/operator impact

No production code changes in this PR. This is the design gate for later implementation slices. The proposed first implementation slice is an executable deterministic test harness and nix flake check contract before correctness fixes are made.

Validation

• audited active StarRouter broker/client/protocol/test/build sources
• audited StarIntel Server messaging, architecture, HTTP, and producer sources
• cross-checked reliability design against primary ZeroMQ and RabbitMQ documentation
• verified branch diff contains 9 new Org design files and no production-code changes

Runtime execution was not performed in the current environment because a local checkout could not reach GitHub; the documents explicitly distinguish source-verified findings from runtime hypotheses that the new harness must reproduce.