fix(metadata-protocol): per-item publish re-binds runtime consumers and finds env-wide drafts - #10291

Fixes #10219

The per-item publish door — POST /api/v1/meta/:type/:name/publish, the one AI authoring
and the item-level Studio doors take — was missing two things the package-scoped door has.
Both are fixed at the producer, so every transport that reaches the protocol inherits them.

A — a publish now announces metadata:reloaded on both doors

metadata:reloaded is the platform's declared "re-read what you cached" signal, and it had
exactly two announcers: the metadata plugin's dev-artifact watcher, and the runtime
dispatcher after POST /packages/:id/publish-drafts (#2576). Publishing item by item fired
neither. Measured on a cloud rig: two flows published as state='active' produced no bind
log and never executed; only a forced kernel rebuild picked them up, via the kernel:ready
cold-boot bind (#2560). Same silence for other packages' authored hooks/actions, declared
connectors and authored translations.

publishMetaItem now notifies through a new onMetaItemPublished seam, and
ObjectQLPlugin.subscribeMetadataRebind — armed for both protocol assembly modes —
turns that into ctx.trigger('metadata:reloaded', { changed }). The producer notifies and
the host announces because the protocol holds no kernel hook bus; that is the same division
HttpDispatcher.announceKernelEvent already makes for the batch door. changed carries the
batch door's {type}/{name} spelling, so a subscriber cannot tell the two doors apart.

Three deliberate choices, each pinned by a case:

• Not the existing onMetadataMutation. That event is emitted from
  runPublishSideEffects, which the batch door runs once per promoted draft — announcing on
  it would fan a full kernel re-sync (schema DDL, connector re-materialization, flow re-bind)
  out once per item of a "publish whole app". A CONTROL case pins that the batch door emits
  none of the new event, so its single per-publish announce is unchanged.
• Awaited, so the publish's own 2xx means the re-bind was attempted rather than queued —
  a caller that publishes a flow and immediately writes a record must not race the bind.
• No new wire key. The batch door carries rebindError because its response is a batch
  receipt; adding a zero-reader diagnostic key to PublishMetaItemResponseSchema buys no
  capability (the objectui: the Unpublished banner and per-app publish read _unpublished; the App Switcher keeps filtering on hidden (#4829 A1 objectui half) #6955 ruling, one payload over), so a failed announce is reported through
  the log — warn, matching the sibling announcers — and never fails the publish.

B — a per-item publish now resolves the draft's own org scope

Four AI-authored view drafts sitting at state='draft' in sys_metadata, listed by the
console's pending-changes banner and promoted by its one-click "publish 4 changes" button,
were each refused per item with 404 [no_draft] No pending draft exists for view/<name> — nothing to publish.

view is one of the types the registry declares allowOrgOverride: true, so
organizationIdForMetaWrite threads the session's active organization into the publish. The
drafts were authored env-wide (organization_id = NULL) — what package/AI authoring writes —
and a strict organization_id = <org> lookup can never match them. object and flow are
not org-overridable, which is exactly why per-item publish worked for them and failed for
views: one symptom, split by a registry flag.

This is the single-item twin of #3115. The batch door fixed it by discovering each
draft's scope (listDrafts surfaces a non-null-org caller's own rows and the env-wide ones
through its $or, and the promote targets d.organizationId); the per-item door deduced
one instead. It now discovers, with the ADR-0005 precedence — an org holding its own draft
publishes that one, and only an org with no draft of its own falls through to the env-wide
row it was already authoring into. Resolved before every gate below it, so the ADR-0010 lock
check, the #6190 org-scoped-write refusal and the promote all judge the one scope the row is
actually in. When neither scope holds a draft, the caller's own scope is returned unchanged,
so a genuinely absent draft still raises the same NO_DRAFT refusal. No catch: a driver
failure fails the publish rather than resolving to a scope nobody verified.

Regression coverage — the chain, end to end

The issue's requirement 3 ("publish a record-change flow per item, write a record, assert it
executes") is pinned as three links rather than one integration test, because the third link
already had one:

Defect B has its own file, protocol.publish-item-draft-org-scope.test.ts (4 cases), with
the org-precedence and still-NO_DRAFT controls beside the fix.

Reverse verification. With the B hunks removed from the committed tree (helper deleted
and its call site deleted; confirmed on disk by asserting resolveDraftOrgScopeForPublish
no longer appears in the file), the org-scope file goes 2 failed | 7 passed, failing with
the issue's exact sentence — [no_draft] No pending draft exists for view/customer_list — nothing to publish. — while the PRECEDENCE and NO_DRAFT controls stay green (they do not
depend on the fallback) and the announce file stays entirely green, so the two fixes are
independent. Restored, all 9 pass again. The tests import the mutated module from source in
its own package, so no dist rebuild is involved on either leg.

Verification

Run at 713a78452 (the final commit):

• pnpm --filter "@objectstack/objectql^..." build → exit 0 (dependency closure, built first)
• pnpm --filter @objectstack/metadata-protocol test → Test Files 126 passed | 2 skipped, Tests 1717 passed | 10 skipped
• pnpm --filter @objectstack/objectql test → Test Files 222 passed (222), Tests 3925 passed (3925)
• pnpm --filter @objectstack/objectql typecheck → exit 0 (metadata-protocol declares no
  typecheck script — it is a measured entry in the coverage ledger; its tsup DTS build is
  the type signal it has, and it succeeded)
• gate union derived by node scripts/pm/dispatch-gates.mjs (no paths), re-run at
  713a78452: check:nul-bytes, check:cross-package-test-inputs,
  check:durability-log-level, check:filter-alias-parity, check:slot-lookup,
  check:engine-double-contract, check:where-matcher, check:query-options-erasure,
  check-adr-0087-registration, check-changeset-no-major, check-empty-changeset — all
  exit 0. check:engine-double-contract first reported the two new stub engines as unpinned
  coverage; regenerated with --write (4 rows added or grown, 0 lost) in its own commit.

Two gates in the derived list fail identically on an untouched main checkout
(68f65ff60) on this macOS host and are unrelated to this change:
check:changeset-gate-self-tests (its check-adr-0087-registration --self-test I2 cases:
the gate spawned inside the temp fixture exits 0 and prints nothing) and
check:objectui-changeset (ENOENT on a /var/folders/.../objectui-digest-selftest-*
fixture path). Both are self-test/fixture failures in a temp directory, neither reads a file
this PR touches, and CI runs them on Linux.

scripts/pm/os-verify-lock.sh could not be used on this host — filed separately, see below.

Out of scope

• scripts/pm/os-verify-lock.sh spins forever on bash 3.2 (macOS): mapfile/EPOCHSECONDS are bash 4+/5+, so the lock is never acquired and the command never runs #10289 — scripts/pm/os-verify-lock.sh uses bash-4-only builtins
  (mapfile, EPOCHSECONDS) behind #!/usr/bin/env bash, so on macOS's bash 3.2 it never
  acquires and never runs the command: it spins, emitting mapfile: command not found /
  EPOCHSECONDS: unbound variable forever. Measured here with all three of this round's dev
  sessions stuck in it simultaneously. The build/test commands above were therefore run
  directly, with --workspace-concurrency=2 to keep the load bounded — a declared narrowing,
  not a silent one.

Generated by Claude Code