fix(automation): bind a flow published while the server runs, without a restart - #2576

…ublish

`POST /api/v1/meta/:type/:name/publish` promoted a draft to `active` and told
nobody. The lifecycle event that makes boot-cached consumers re-read had two
announcers — the metadata plugin's dev-artifact watcher, and the runtime
dispatcher after `POST /packages/:id/publish-drafts` (#2576) — so publishing
item by item, which is what AI authoring and the item-level Studio doors do,
fired neither. Measured on a cloud rig: a record-change flow published as
`state='active'` produced no bind log and never executed until the kernel was
rebuilt and `kernel:ready` re-bound it (#2560).

`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, which is the same division `HttpDispatcher.announceKernelEvent` makes
for the batch door. `changed` carries the batch door's `{type}/{name}` spelling,
so a subscriber cannot tell the two doors apart.

The notification is deliberately NOT the existing `onMetadataMutation`: that one
is emitted from `runPublishSideEffects`, which the batch door runs once per
promoted draft, so 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.

Awaited, so the publish's own 2xx means the re-bind was attempted rather than
queued; best-effort, so a throwing subscriber is logged at `warn` and never
turns a landed publish into an error. No wire key is added — the batch door's
`rebindError` exists because its response is a batch receipt, and adding a
zero-reader diagnostic key to `PublishMetaItemResponseSchema` buys no capability.

Part of #10219

…nd finds env-wide drafts (objectstack-ai#10291)

* fix(metadata-protocol): announce metadata:reloaded after a per-item publish

`POST /api/v1/meta/:type/:name/publish` promoted a draft to `active` and told
nobody. The lifecycle event that makes boot-cached consumers re-read had two
announcers — the metadata plugin's dev-artifact watcher, and the runtime
dispatcher after `POST /packages/:id/publish-drafts` (objectstack-ai#2576) — so publishing
item by item, which is what AI authoring and the item-level Studio doors do,
fired neither. Measured on a cloud rig: a record-change flow published as
`state='active'` produced no bind log and never executed until the kernel was
rebuilt and `kernel:ready` re-bound it (objectstack-ai#2560).

`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, which is the same division `HttpDispatcher.announceKernelEvent` makes
for the batch door. `changed` carries the batch door's `{type}/{name}` spelling,
so a subscriber cannot tell the two doors apart.

The notification is deliberately NOT the existing `onMetadataMutation`: that one
is emitted from `runPublishSideEffects`, which the batch door runs once per
promoted draft, so 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.

Awaited, so the publish's own 2xx means the re-bind was attempted rather than
queued; best-effort, so a throwing subscriber is logged at `warn` and never
turns a landed publish into an error. No wire key is added — the batch door's
`rebindError` exists because its response is a batch receipt, and adding a
zero-reader diagnostic key to `PublishMetaItemResponseSchema` buys no capability.

Part of objectstack-ai#10219

* fix(metadata-protocol): resolve the draft's own org scope on a per-item publish

The per-item publish door could not SEE a draft the batch door published fine.
Measured on a cloud rig: four AI-authored `view` drafts sitting at
`state='draft'` in `sys_metadata` — listed by the console's pending-changes
banner, 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`), which is
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 objectstack-ai#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 objectstack-ai#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
from the scope it asked about. No `catch`: a driver failure must fail the
publish rather than resolve to a scope nobody verified.

Fixes objectstack-ai#10219

* chore: record the two new fake engines in the engine-double ledger

`check:engine-double-contract` retains a per-file pin for every test double that
routes its `delete()` / `update()` through `assertEngineDeleteDispatch` /
`assertEngineUpdateDispatch`. The two stub engines added with this card's
regression tests are pinned coverage the ledger did not know about, so it was
not protecting those files. Regenerated with `--write`: 4 rows added or grown,
0 lost.

Part of objectstack-ai#10219

---------

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>