Integrate release recovery, semantic review, coverage and Windows packaging

docs/language.rst

@@ -286,7 +286,7 @@ references. Their kind is the declaration keyword:
      - Work, participant, capability, or process/chain → state/mode
      - None
    * - ``exchange_allocation``
-     - Boundary-exchange relation → SA functional-exchange relation
+     - Boundary-exchange relation → same-layer interaction (OA) or functional exchange (SA)
      - None
    * - ``interface_provision``, ``interface_requirement``
      - Participant/port → provided/required interface
@@ -1662,6 +1662,55 @@ the line. Structural errors and engineering warnings point to a relevant
 declaration or field when available. Clients MUST use severity/code rather than
 parse the human message; diagnostic wording is not a stable machine API.
 
+.. rubric:: Explicit behavior coverage diagnostics
+
+The following shared engineering checks are advisory ``Warning`` diagnostics.
+They MUST NOT reject graphical Apply, source compilation, Save, or an API
+transaction solely because the model is incomplete. They run only after the
+structural pass reports no ``Error``, avoiding cascades from invalid ownership,
+references, layers, or recursion. Their policy concerns explicit evidence in
+the authored model, not proof that no engineering behavior exists.
+
+* ``non_leaf_work_exchange`` locates each ``source`` or ``target`` of an
+  Interaction or FunctionalExchange that has direct same-kind child work.
+  Repair the exchange to name its responsible leaf Activity/Function, keeping
+  SA function-port ownership consistent.
+* ``work_without_behavior_context`` locates a leaf Activity/Function lacking
+  an included Action or an included Interaction/FunctionalExchange occurrence
+  that explicitly names it as an endpoint.
+* ``exchange_without_behavior_context`` locates an Interaction or
+  FunctionalExchange lacking an included Exchange occurrence. It is suppressed
+  while a more specific non-leaf endpoint warning applies to that exchange.
+* ``mission_without_capability`` locates an OperationalMission/Mission lacking
+  a valid same-layer outgoing MissionCapability. Participant responsibility
+  through MissionInvolvement does not satisfy this check.
+* ``capability_without_behavior_context`` locates a supported leaf
+  Capability/SystemCapability lacking either an incoming ChainInvolvement or
+  a same-layer Scenario explicitly naming it as ``context``. It MUST NOT
+  duplicate ``unsupported_capability`` on the same record.
+
+Record-level checks have no invented field path. Coverage traverses all Process,
+FunctionalChain and Scenario roots, following only their explicitly listed,
+correctly owned occurrences and Fragment branches. Reusable sequence/scenario
+contents are traversed with identity-based cycle guards. Known work/exchange
+references count despite unfinished lifelines; unordered occurrences do not.
+Repeated exchanges and correlated replies contribute the same identity once.
+Parent work does not cover its children. Bare lifelines, state observations,
+StateAction/Availability links, timer-only occurrences, and participant/boundary
+messages do not imply work/exchange coverage. Allocation does not imply that
+every exchange carried by a boundary message occurs. Diagram layout is irrelevant.
+
+As an explicit Studio completeness policy, same-kind capability grouping parents
+are excluded from both capability support warnings; their leaf capabilities are
+checked independently. A valid direct Scenario context also satisfies existing
+``unsupported_capability`` support. An empty linked process/chain or scenario
+satisfies explicit context presence while retaining its own ``empty_sequence``
+warning. Include/extend/generalization, parent containment, and shared performers
+MUST NOT manufacture a context. These advisory checks follow the distinction
+between dataflow and its usage contexts described in the official
+`Arcadia Questions and Answers <https://mbse-capella.org/arcadia-qna.html>`_;
+they are not a declaration of full Capella conformance.
+
 ``parse_limited`` and ``decode_limited`` accept caller admission budgets for
 input bytes, graph objects, total persistent records and ordered step references.
 Counts MUST be checked before expensive structural validation; migration budgets