docs(project): record the protocol state-machine design

[devin-ai-integration]

What and why

The roadmap's protocol-state-machines item left one piece of work: a design record settling whether SysML v2 has a standard construct for what UML 2.5.1 §14.4 calls a protocol state machine, and whether OpenSysML already runs it. This PR adds that record, docs/project/protocol-state-machines.md, and re-words the roadmap section and the spec-compliance.md bullet to its conclusion. No runtime change.

The record's language finding: there is no SysML v2 counterpart to ProtocolStateMachine, and none is needed for the half of the idea the language can express. The legal order of receptions on a port or part is an ordinary exhibited behavior state machine (§7.18.4, accept … via §7.17.8; KerML StatePerformance.acceptable/accepted/deferrable), which the runtime lowers, starts with the exhibiting object and fires in the declared order on parts as the OMG corpora write it (ServerSequenceRealization-2.sysml; conformance state_transition_accept_via_port). What SysML v2 cannot spell — gating operation calls by state, post-conditions, ProtocolConformance, static sequence checking — is a UML feature the language dropped, not an OpenSysML gap.

The record's runtime finding, from two probes reproduced in it: the declared order is enforced only for events a debugger injects directly (StateExecutor.SendSignal → dispatched, dropped, AdvanceReport.Dropped; the REPL's %send refuses one by machine and state). A message a model sends that the active state neither accepts nor defers is not dropped — it stays on the context-wide bus (state_executor.go:takesMessage) and is taken by the first later state that accepts it, so Read, Open, Read sent to a machine in closed ends with reads = 2 and nothing reported. A machine exhibited by a port definition runs and answers the debugger's messages to the port object, but does not take a model's messages routed to that port.

Recommendation: keep the item open with the follow-up the record specifies — a message addressed to a performer whose started machines all refuse it is taken off the bus and dispatched as a non-firing dispatch (so it is reported as the direct path reports it, the UML/PSSM discard rule); a port definition's machine takes the messages routed to its port; optionally an opt-in policy that makes the drop a typed error. No IR change; proof fixtures written in the record; two routing points to settle first. The compliance bullet is re-worded to say the notation runs and its order is enforced only for debugger-injected events. The corpus search (374 files) found no exhibit inside a port def/interface def, no Protocol, and HappensBefore/HappensDuring only in library and occurrence examples.

How it was verified

Documentation only. go build ./..., go vet ./..., gofmt -l . empty, go test ./... green, make docs-check (links, doc-ids, figures, changelog fragment) clean, and the corpus gates with the corpora at their pin: OPENSYSML_REQUIRE_TRAINING_CORPUS=1 OPENSYSML_REQUIRE_PILOT_CORPORA=1 go test -count=1 ./tests/corpus -run 'TestTrainingExamples|TestPilotCorpora' ok. The probes in the record were run against this tree: the port-definition probe through bin/sysml, the model-send probe through a throwaway runtime test (Context.Instantiate, Context.Advance, Context.PendingMessages) that is not committed.

Checklist

• make test and make lint pass locally
• Tests added or updated for the change (none: documentation only)
• Documentation extended where it already covers the surface (see CONTRIBUTING.md)
• Changelog entry added as changes/unreleased/<slug>.<section>.md, not as an edit to CHANGELOG.md
• baselines regenerated and make docs-counts run if a gate count moved (no count moved)
• No internal work-item labels (waves, slices, F4, K5) in the body, docs, or changelog

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Confirmed, and it is worse than "not reported": with the machine on the part (accept Open via f / accept Read via f) and a sibling machine's entry sending Read, Open, Read to file.f, the early Read stays on the bus and is taken once Open has moved the machine to opened — final reads = 2, AdvanceReport.Dropped empty. With the machine on the port definition, all three messages stay pending forever (DeliverPort to the part's port; the port object's own machine never takes them).

Corrected in 9d768d3: the table row and gap now distinguish the direct-injection path (SendSignal → dispatched → Dropped) from the bus path (takesMessage false → held, taken later); probe 2 with both variants and its observed values is in the record; the recommendation is now "keep the item open" with the runtime follow-up specified (drop-and-report an addressed message no started machine of its destination accepts or defers; port-definition machine takes messages routed to its port; optional typed error). Roadmap section, compliance bullet (now ⚠️, not "covered") and the changelog fragment say the same.