fix(metadata-protocol): the write refusal reports the package door, not only the type's flags (#7682)

`PUT /api/v1/meta/object/showcase_task` answered `403 NOT_OVERRIDABLE`
identically whether `?package=` named a read-only or a writable package:
`SysMetadataRepository.assertAllowed` discriminated on the metadata TYPE's
registry flags and never read the base the caller named. `ITEM_LOCKED` and
`WRITABLE_PACKAGE_REQUIRED` are both registered to this package in the
error-code ledger and neither was ever emitted on this path.

The refusal branch now reads the named base through the shared
`isWritablePackage` predicate (imported from `package-writability.ts`, the same
one `saveMetaItem`'s ADR-0070 D1 gate and the `/packages` lifecycle gate use):

  * `override-artifact` into a read-only base -> 403 ITEM_LOCKED, carrying
    ADR-0010's reserved `lockSource: 'package'` and the package id. "Pick a
    writable base" would be a false prescription here, so the code names the
    lock instead.
  * `runtime-only` into a read-only base -> 422 WRITABLE_PACKAGE_REQUIRED, the
    same code, status and prescription `saveMetaItem` already emits for exactly
    this condition, now also stated at the single persistence route.

No ALLOW decision moves: every allow limb returns before this point, so an
ADR-0005 overlay (which names the read-only package it customizes by
construction) and the documented `OS_METADATA_WRITABLE` hatch behave exactly as
before -- both pinned, the hatch because #8146 must be free to move it
deliberately. A write naming no base keeps the previous codes verbatim, and the
DELETE verb is untouched (#6960).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmES43BMDg4bPrxTdi5q7t

Author: claude

.changeset/metadata-refusal-package-writability.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/metadata-protocol": patch
+---
+
+fix(metadata-protocol): the metadata write refusal reports the package door — `ITEM_LOCKED` / `WRITABLE_PACKAGE_REQUIRED` are emitted where they apply (#7682)
+
+`PUT /api/v1/meta/object/showcase_task` answered `403 NOT_OVERRIDABLE`
+("'object' is not allowOrgOverride in the registry") — the **same** code, status
+and sentence whether `?package=` pointed at a **read-only** package or a
+**writable** one. The refusal discriminated on the metadata TYPE's registry
+flags and never read the base the caller named, so the two codes the error-code
+ledger registers to this package for the package-writability condition —
+`ITEM_LOCKED` and `WRITABLE_PACKAGE_REQUIRED` — were never emitted on this path
+at all. Declared, not enforced.
+
+`SysMetadataRepository.assertAllowed` now reads the named base through the
+shared `isWritablePackage` predicate (the same one `saveMetaItem`'s ADR-0070 D1
+gate and the `/packages` lifecycle gate use — imported, not re-spelled), and a
+refused write that named a read-only base says so:
+
+- **`override-artifact`** (an artifact backs the name, and it ships from a
+  package the deployment provides) → `403 ITEM_LOCKED`, carrying
+  `lockSource: 'package'` — ADR-0010's own reserved value for a lock the package
+  layer asserts — plus the package id. `WRITABLE_PACKAGE_REQUIRED` would be the
+  wrong prescription here: switching bases cannot help, because the artifact is
+  code-shipped wherever the caller points. This is the server-side counterpart
+  of the "Read-only" badge Studio already renders.
+- **`runtime-only`** (no artifact under this name — a NEW item authored into a
+  read-only base) → `422 WRITABLE_PACKAGE_REQUIRED` with the package id, the
+  same code, status and prescription `saveMetaItem` already emits for exactly
+  this condition. One vocabulary, now stated at the single persistence route as
+  well, so callers that do not pass through that gate cannot skip it.
+
+**No allow decision moves.** Every write that succeeded before still succeeds:
+this is the code selection inside the refusal branch, not a new gate. That
+distinction is load-bearing rather than cautious — an ADR-0005 org overlay names
+the read-only package it customizes *by construction*, so a package door that
+refused would close the overlay model itself. In particular the documented
+`OS_METADATA_WRITABLE` hatch is untouched: an env-hatch write into a read-only
+package (`OS_METADATA_WRITABLE=permission` + a `permission` set belonging to a
+read-only package) still succeeds, and is now pinned by a test — whether that
+hatch or Studio's badge is the correct semantics is a separate maintainer
+decision (#8146) and must move deliberately, not as a side effect of this fix.
+Writes that name no base keep the previous `NOT_OVERRIDABLE` / `NOT_CREATABLE`
+codes verbatim, and the DELETE verb is unchanged (#6960 moved that side on
+purpose; `DeleteOptions` names no package).
+
+Reachability, stated so it is not mistaken for more than it is: this refusal is
+what answers on the host-config topology (`environmentId` undefined — the CLI's
+lightweight assembler, i.e. the flagship showcase and self-hosted servers shaped
+like it), which is the topology the defect was measured on. On a scoped kernel
+`saveMetaItem` refuses earlier, in `protocol.ts`, still with the undiscriminated
+`NOT_OVERRIDABLE`; that second refusal point is filed separately.