Publish documents to CALM Hub via calm workspace

## Feature Proposal

### Target Project:
`cli` (`calm workspace`), integrating with `calm-hub` (the new Document endpoint).

### Description of Feature:
Extend the CALM Workspace flow so a user can publish a document to CALM Hub from their workspace and we can demo the published document end-to-end. This is the user-facing slice that ties the PoC together, and it realises the agreement in #2866 that documents are *"version controlled and pushed to CALM Hub with the same mechanism as `calm workspace`"*.

### User Stories:
- As an architect, I want `calm workspace push` to publish my document to CALM Hub so that I can demonstrate a document going from local workspace to a live Hub registry, versioned alongside its architecture.
- As a reviewer, I want to open the published document from CALM Hub after a push so that the demo proves the full loop.

### Current Limitations:
- `calm workspace` can push CALM artefacts today, but has no step to publish a document to a documents endpoint and no notion of a document artefact. The current workspace/Hub command overlap and gaps are catalogued in #2539.

### Proposed Implementation:
- Extend `calm workspace push` (or add a dedicated publish step) to send the workspace's document(s) to the new namespace-scoped documents endpoint (`/api/calm/namespaces/{namespace}/documents/{document-type}`), honouring CALM Hub auth.
- Because documents ride the existing workspace mechanism, workspace `check` (drift detection) and `bump` (coordinated versioning) apply automatically - the document is versioned alongside its architecture.
- Record the published document's Hub location/id back into the workspace manifest so `list` reflects publish state.
- Demo path (local, no-auth / standalone Hub):
1. Initialise a workspace and add a sample architecture + a document.
2. `calm workspace push` → validates + publishes the document.
3. Retrieve it from CALM Hub (API or UI) to confirm the loop.
- Dependencies: the Document endpoint and validation issues must land first.

### Alternatives Considered:
- A separate `calm publish` command decoupled from workspace - possible, but the PoC goal is to demo the *workspace* publishing a document, so integrate with `workspace`.
- Manual upload via the API - rejected; the value is an automated, versioned publish.

### Testing Strategy:
- CLI unit tests for the push→publish path (mocked Hub client) and manifest update.
- A scripted end-to-end demo against a local CALM Hub asserting the document is retrievable after push.

### Documentation Requirements:
- `calm workspace` documentation: the publish flow and the demo steps.

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

### Additional Context:
- This is the demo-able outcome of the PoC value cycle: workspace → validate → publish → retrievable in CALM Hub.
- Command placement should be consistent with the workspace/Hub surface analysed in #2539; related CLI publishing commands are in #2377, and workspace acceleration in #2237.
- the document format is defined in #2866; the underlying decision is #2791.

Start with the `calm workspace push` entry point and review how workspace `check`, `bump`, and `list` handle artefacts and manifests. Read #2539, #2866, and #2791, then confirm the Document endpoint and validation dependencies are available. Done means a document is validated, published to the namespace-scoped Hub endpoint, recorded in the manifest, retrievable after push, and covered by CLI and end-to-end tests.

Written by the indexing model from the issue text.