feat(publish): atomic expected workspace incarnation fence on publish_bytes #508

Summary

Expose an atomic expected workspace incarnation fence on Client.publish_bytes (and the underlying publish path), so a caller that binds durable state to one workbench incarnation can refuse to write after that workbench was removed and recreated, instead of detecting the mismatch only after the write landed.

Context

LoopX's Stage 2A NoKVAuthorityStore candidate (loopx-project/loopx#3819, merged) stores one authority envelope per goal at metadata/loopx-authority/<digest>.json and uses NoKV as follows:

• find_workspaces → workspace_incarnation_id is the store lineage identity;
• read(workbench, path) → envelope bytes plus metadata.generation and the incarnation;
• publish_bytes(workbench, path, data, content_type="application/json", expected_generation=..., operation_id=..., artifact_revision_id=...) → path-level generation CAS.

Today the adapter fails closed through post-write readback: it accepts even a successful publish only after a fresh read proves the exact transaction under the current workbench incarnation. That closes false success at the LoopX boundary, but it cannot prevent the write itself when the workbench was recreated between the identity read and the publish (generations restart at 1 on recreation, so a stale expected_generation can match again). LoopX records this as an explicit provider-contract hold ("preventing the stale-incarnation write itself requires a future provider primitive", examples/nokv-authority-store/README.md and RFC Appendix A).

The metadata layer already carries this notion for workspace commits: crates/nokv-meta/src/workspace/commit.rs checks expected_source_workspace_incarnation_id and rejects a commit whose workspace incarnation moved. Publish has no equivalent parameter.

Proposal

1. publish_bytes(..., expected_workspace_incarnation_id: str | None = None) (Python API; the Rust publish_artifact options gain the same optional field). When set, the server evaluates it in the same atomic step as expected_generation against the target workbench's current incarnation.
2. A typed rejection distinct from the generation conflict, for example WorkspaceIncarnationMismatch { expected, current }, surfaced as its own Python exception class rather than a RuntimeError string, so an SDK caller can classify it without parsing text (LoopX currently has to treat every RuntimeError from publish as ambiguous).
3. The publish result echoes the incarnation the write landed in (workspace_incarnation_id), matching what read metadata already returns.
4. No change to callers that omit the parameter.

Acceptance

• A publish with a stale expected_workspace_incarnation_id after workbench remove + recreate is rejected atomically and leaves no object or generation behind; the same call with the current incarnation succeeds.
• The rejection is typed on the wire and in the Python SDK, and is idempotent with operation_id replay semantics (a replayed request carries the same fence).
• expected_generation and expected_workspace_incarnation_id are checked together; no window exists where one passes and the other is evaluated against a different workspace state.
• Documented in the Python API reference and the metadata schema notes.

Why it matters for the collaboration

This is the last provider-side hold named by the LoopX Stage 2A qualification. With it, the authority store can move from "detect and fail closed after the fact" to "the stale lineage cannot write at all", which the Shared Goal Authority RFC needs before any shared-mode promotion (Stage 3 onward).