fix(metadata-protocol): the ADR-0010 lock gate must not fail open (#5706) (#5736)

`getEffectiveLock` is the only source of truth for the ADR-0010 §3.3 lock
gate, and both callers are write-path admission — `assertLockAllowsWrite`
(save/publish/rollback) and `assertLockAllowsDelete`. Its overlay read was
wrapped in a bare `catch` that fell through to `lock: 'none'`.

`'none'` is not a neutral placeholder there: it is the verdict "the author
declared no protection", which `evaluateLockForWrite` /
`evaluateLockForDelete` turn straight into "allow". A `sys_metadata` read
that FAILED therefore became a write that was PERFORMED on an item whose
overlay row declared it protected. Measured on origin/main, with the row
carrying `_lock` and only the gate's own read rejecting: `saveMetaItem`
resolved `success: true` after `update:sys_metadata` on a `no-overlay`
item, and `deleteMetaItem` the same on a `no-delete` one — while the same
rows read successfully produce 403 ITEM_LOCKED. The audit trail did not
compensate: the allowed path writes its ordinary `outcome: 'allowed'` row.

Reuses `rethrowUnlessMetadataStoreUnprovisioned` (#5705) rather than
inventing a second predicate — an unprovisioned `sys_metadata` genuinely
has no overlay row, so `'none'` is the truth and first boot still saves;
every other error becomes 503/SERVICE_UNAVAILABLE with the driver error as
`cause`. Wire-visible, and deliberate: refusing one uncertain write beats
performing one that had to be refused.

Unaffected and pinned by regression tests: artifact-level locks (answered
from the in-memory registry before the overlay read), a genuine miss on a
healthy store, and control-plane kernels.


Claude-Session: https://claude.ai/code/session_01V7WetGmnfoXNn8cLieKKmx

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang

.changeset/lock-gate-fail-closed.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/metadata-protocol": patch
+---
+
+fix(metadata-protocol): the ADR-0010 lock gate refuses an uncertain write instead of allowing it (#5706)
+
+`getEffectiveLock` is the single source of truth for the ADR-0010 §3.3 lock
+gate, and both of its callers are write-path admission — `assertLockAllowsWrite`
+(save / publish / rollback) and `assertLockAllowsDelete`. Its overlay read was
+wrapped in a bare `catch` that fell through to `lock: 'none'`.
+
+`'none'` is not a neutral placeholder there. It is the verdict "the author
+declared no protection", and `evaluateLockForWrite` / `evaluateLockForDelete`
+turn it straight into "allow". So a `sys_metadata` read that **failed** became a
+write that was **performed**, on an item whose overlay row declared it
+protected. Measured before the fix, with the overlay row carrying `_lock` and
+only the gate's own read rejecting: `saveMetaItem` returned `success: true`
+after updating a `_lock: 'no-overlay'` item, and `deleteMetaItem` returned
+`success: true` after deleting a `_lock: 'no-delete'` one — while the very same
+rows, read successfully, produce `403 ITEM_LOCKED`. The audit trail did not
+record the miscarriage either: the allowed path writes its ordinary
+`outcome: 'allowed'` row, so nothing afterwards showed the write should have
+been denied.
+
+**Wire-visible change.** When the lock state cannot be read, `save`, `publish`,
+`rollback` and `delete` now fail with `503` / `SERVICE_UNAVAILABLE` (the driver
+error attached as `cause`) instead of proceeding as if the item were unlocked.
+Refusing one uncertain write is the intended trade against performing one that
+had to be refused. Callers that retry on 503 need no change; callers that
+treated a successful save as proof the item was unlocked never had that
+guarantee.
+
+The discrimination reuses `rethrowUnlessMetadataStoreUnprovisioned`, introduced
+in #5705 for this file's overlay reads, rather than inventing a second
+predicate: an unprovisioned `sys_metadata` genuinely has no overlay row, so
+`'none'` is the truth and first boot still saves normally; every other error is
+an outage.
+
+Unaffected, and covered by regression tests: artifact-level locks (answered from
+the in-memory registry before the overlay read is reached), a genuine miss on a
+healthy store (still allowed), and control-plane kernels (`environmentId`
+undefined), which never enter either gate.