Experimental: Morphir bridge — executable behaviour via a behaviour-provider decorator

## Feature Proposal

### Target Project:

`experimental/`

### Description of Feature:

A loosely-coupled bridge between CALM behaviour specifications and [FINOS Morphir](https://morphir.finos.org), adding an *executable* rung to the behaviour anchoring ladder. Where Given/When/Then scenarios give human-readable acceptance criteria, Morphir gives typed, platform-independent business logic with test cases attached to the model itself (`morphir-tests.json`: function FQName → `{inputs, expectedOutput, description}`, replayable on any Morphir backend).

The bridge is a **behaviour-provider extension** of the behaviour decorator (#2621), using the decorator schema-inheritance pattern already established by the deployment decorators:

```json
{
"type": "behaviour",
"data": {
"provider": "morphir",
"distribution-url": "https://models.example.com/order-pricing/morphir-ir.json",
"fqname": "Example.Orders:Pricing:calculatePrice",
"test-suite-url": "https://models.example.com/order-pricing/morphir-tests.json"
}
}
```

No code dependency in either direction: the linkage is URLs and FQName strings. Traceability can be made bidirectional using each project's native extension mechanism — the CALM decorator points at a Morphir FQName; a Morphir *decoration* (its sidecar metadata mechanism) points back at a CALM element `unique-id`.

### User Stories:

As an architect in a regulated domain, I want a CALM node's critical business logic (pricing, eligibility, regulatory calculations) to reference a Morphir model and its test suite, so that the architecture links to verifiable, executable behaviour rather than prose.

As a compliance reviewer, I want a control requirement satisfied by evidence that the referenced Morphir test suite passes, so that "business logic verified" is machine-checkable.

As a developer, I want Morphir test cases surfaced as the data examples for a scenario anchored to the same element, so that human-readable specs and executable tests share one source of truth.

### Current Limitations:

CALM behaviour specs (Given/When/Then) capture intent and acceptance criteria but are not executable semantics. There is no mechanism to link a CALM element to formally modelled, testable business logic.

### Proposed Implementation:

A spike in `experimental/` with three deliverables:

1. **The `morphir` behaviour-provider decorator schema** — an `allOf` extension of the base behaviour decorator constraining `provider: "morphir"` and defining the `data` shape above.
2. **A coherence checker** — a small tool that resolves a referenced `morphir-ir.json` against Morphir's published IR JSON Schemas (v3 current), verifies the named FQNames exist in the distribution, and confirms the test suite references resolve. Coherence checking only — no test execution; running tests stays with Morphir tooling and CI, with results returned via the standard evidence pointer.
3. **A worked example** — a small architecture with a flow, scenarios anchored to it, a Morphir model implementing one transition's logic with matching test cases, and decorators linking both ways.

Dependencies: the behaviour document type and behaviour decorator (#2621). Nothing here touches core schemas.

A follow-up step, if the spike proves out, is to engage the Morphir community on standardising the decoration convention on their side (the CALM-element back-reference), so the bidirectional linkage is a published convention in both projects rather than a CALM-side pattern only.

### Alternatives Considered:

- **Importing the Morphir IR into calm-models** — rejected: the IR format is versioned and evolving (v3 current, v4 draft; next-generation tooling in alpha), and a type-level dependency would chain CALM releases to a moving format. URL + FQName strings are immune to all of it.
- **Treating Morphir as the only executable provider** — rejected: the base behaviour decorator is provider-agnostic by design; Morphir is the first provider extension, not a privileged dependency. Contract-test providers (e.g. Pact-style) can follow the same shape.
- **Executing Morphir tests from CALM tooling** — rejected: CALM stores intent and evidence pointers; execution belongs to the provider's toolchain and CI.

### Testing Strategy:

- Unit tests for the coherence checker against fixture distributions (valid, missing FQName, schema-invalid, wrong format version).
- The worked example validates end-to-end via `calm validate` plus the coherence checker.
- Follows the `experimental/` feedback process for graduation criteria.

### Documentation Requirements:

- A README in the experimental package explaining the layered model (structure → process → behavioural intent → executable semantics), the provider pattern, and the worked example.

### Implementation Checklist:

- [ ] Design reviewed and approved
- [ ] Implementation completed
- [ ] Tests written and passing
- [ ] Documentation updated
- [ ] Relevant workflows updated (if needed)
- [ ] Performance impact assessed

### Additional Context:

Part of the behaviour-driven architecture work — see the tracking issue finos/architecture-as-code#2627. Positioning matters: Morphir is an optional deep-verification tier for the logic that warrants it (regulatory calculations, pricing, eligibility), never a prerequisite for using behaviour specifications.

Start in experimental/ and read the behaviour document and decorator work from #2621, then inspect the referenced morphir-ir.json and morphir-tests.json shapes. Done means a provider schema, coherence-checker tests covering valid and invalid fixture distributions, a worked example validated with calm validate, and an experimental README.

Written by the indexing model from the issue text.