CALM Hub: behaviours resource type and draft promotion gate

## Feature Proposal

### Target Project:

`calm-hub`

### Description of Feature:

Two related additions that make CALM Hub the governance backstop for the behaviour-driven architecture work:

1. **Behaviours as a resource type** — behaviour documents (#2621) become a first-class Hub resource alongside architectures, patterns, and standards: namespaced CRUD and versioning, following the existing resource conventions.
2. **Draft promotion gate** — Hub enforces the lifecycle-status promotion guard (#2620) at the API boundary: publishing or promoting an architecture version (or timeline moment) that still contains `status: draft` constructs is rejected. The guard moves from advice to governance.

### User Stories:

As a business analyst, I want to publish a standalone behaviour document to the Hub so that it is reviewable and versioned before any architecture exists.

As a platform owner, I want promotion of an architecture out of draft to be rejected while it still contains draft constructs, so that approved architectures never silently contain uncommitted design.

As an architect, I want the rejection response to list the offending draft constructs, so that the promotion burn-down is actionable from the API.

### Current Limitations:

- Hub has no resource type for behaviour documents; rung-0 (unanchored) specs have nowhere governed to live.
- Hub has no notion of lifecycle status; nothing prevents publishing an architecture full of placeholder constructs as if it were approved.

### Proposed Implementation:

- REST endpoints for behaviours following the existing architecture/pattern/standard conventions (namespaces, versions, meta); OpenAPI/Swagger updated.
- Storage in both MongoDB and NitriteDB modes, matching existing resource implementations.
- Promotion gate implemented as server-side validation on the version-creation/promotion paths: reject when the document root is non-draft but draft constructs remain (the same rule the Spectral layer enforces client-side); error payload enumerates the offending construct ids.
- The gate applies to architectures and timeline moments; behaviour documents themselves may also carry draft status and are subject to the same document-level rule.

### Alternatives Considered:

- **Client-side enforcement only (Spectral/CLI)** — rejected as the *only* mechanism: clients can be bypassed; governance needs the server to be the backstop. The Spectral rules remain for fast local feedback.
- **Splitting the gate and the resource type into separate issues** — possible, but both are calm-hub work with one reviewer set and shared test scaffolding; one issue keeps the Java work in one place. Can be split if sizing demands it.

### Testing Strategy:

- Unit tests for the gate logic and behaviours services.
- Integration tests via TestContainers (`../mvnw -P integration verify`) covering both storage modes, CRUD on behaviours, and gate acceptance/rejection paths.

### Documentation Requirements:

- Swagger/OpenAPI for the new endpoints.
- Hub documentation: behaviours resource, promotion gate semantics and error payload.

### Implementation Checklist:

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

### Additional Context:

Depends on the lifecycle-status and behaviour-document schema proposals (#2620, finos/calm-schema#24); both are in draft `2026-03` and this work can develop against the drafts. Part of the behaviour-driven architecture work — see the tracking issue finos/architecture-as-code#2627.

Start by reviewing calm-hub's existing architecture, pattern, and standard resource conventions, then inspect the version-creation and promotion paths and their service tests. Run ../mvnw -P integration verify to exercise both MongoDB and NitriteDB modes. Done means behaviours have governed CRUD and versioning, promotion rejects and enumerates draft constructs, integration paths pass, and OpenAPI and Hub documentation are updated.

Written by the indexing model from the issue text.