fix(runtime): on a kernel-resolver host, resolve a service on the request's own kernel first — record-bound POST /actions stops answering 404 RECORD_NOT_FOUND

[hotlong]

Fixes #22944

Clause-②: no

What was wrong

On a kernel-resolver host (cloud's hosted objectos), HttpDispatcher.resolveService asked the host kernel's scoped lookup first. The host kernel's singleton protocol / metadata / objectql answer getServiceAsync(name, scopeId) whatever the scope. So every dispatcher door that passes context.environmentId read the host's data plane.

The user-visible break: POST /api/v1/actions/:object/:action with a recordId.

1. It loaded its subject row through a protocol that registers none of the environment's objects (OBJECT_NOT_FOUND).
2. loadActionSubjectRecord swallowed that error.
3. refuseDeniedSubjectLoad answered 404 RECORD_NOT_FOUND for a row the caller reads with GET /data/:object/:id in the same session.

The REST data routes never had this, because RestServer.resolveProtocol takes the environment kernel's own protocol. Measured on a hosted-shape rig at cloud v1.36.0's pins; the full reading is on #22944.

The change

resolveService gains one leg. When the request carries a kernel of its own (kernel !== this.defaultKernel), it resolves there first (kernel.getServiceAsync(name, scopeId)), then falls back to the existing chain.

• A request with no kernel of its own is untouched: single-environment hosts, SharedProjectPlugin's scoped factories, and a context whose kernel is the default kernel.
• resolveServiceOrLoud / classifyService keep their order on purpose. That lookup decides which kernel's tenancy answers the identity step, which is a separate question, so its docblock now says so.

Evidence

• New pin: http-dispatcher.request-kernel-first.test.ts, 7 cases on real ObjectKernels.
  • The request kernel wins over a host singleton.
  • A host-only service still falls back.
  • The action door's subject load through the real callData delivers the row.
  • A nonexistent id is still refused 404 RECORD_NOT_FOUND.
  • Three no-request-kernel shapes resolve as before.
• Ablation: with http-dispatcher.ts restored to main, the two cases that carry the defect go red (2 failed / 5 passed); with the fix, 7 of 7 pass.
• @objectstack/runtime suite: 359 files, 5884 passed, 19 skipped.
• End to end on the hosted-shape rig (cloud main, framework 56bf27affb, objectui d758f2f20d, HotCRM 4.0.1; the same change patched into the rig's runtime build):
  • The console's Convert Lead answers 200, its screen opens, and Submit resumes 200. The lead reads converted, with its account, contact and opportunity created.
  • The other record actions sampled (2 script, 3 flow) answer 200.
  • A nonexistent id answers 404.
  • Services whose answer flipped: objectql, metadata, protocol. Nothing else.

Downstream

The consumer is objectstack-ai/hotcrm#2065. It unlocks when cloud's framework pin carries this fix, which cloud tracks separately.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 4 documentable anchor(s).

8 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx (via actions.invoke (sdk, the route ledger binds it to POST /actions/:object/:action))
• content/docs/api/environment-routing.mdx (via HttpDispatcher (symbol, a top-level class))
• content/docs/api/error-catalog.mdx (via actions.invoke (sdk, the route ledger binds it to POST /actions/:object/:action))
• content/docs/automation/flows.mdx (via /actions/:object/:action (route, a path literal in a comment in HttpDispatcher))
• content/docs/automation/webhooks.mdx (via HttpDispatcher (symbol, a top-level class))
• content/docs/kernel/cluster.mdx (via HttpDispatcher (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via HttpDispatcher (symbol, a top-level class))
• content/docs/ui/actions.mdx (via /actions/:object/:action (route, a path literal in a comment in HttpDispatcher))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via /actions/:object/:action (route, a path literal in a comment in HttpDispatcher))
• content/docs/releases/v17/17-1.mdx (via /actions/:object/:action (route, a path literal in a comment in HttpDispatcher))
• content/docs/releases/v17/17-5.mdx (via HttpDispatcher (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 cross-cutting symbol(s) contributed no route anchor: resolveService (9 routes)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 26 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json e357a441c6423798a673d4a39ecee4b31adacf79 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ec2e2e8b868ab96f2aa57ffdbc46b33cb7916f94 — the merge of head 62ca3debd456b4b313fa21c4c3e9e2b0968b76f1 into base e357a441c6423798a673d4a39ecee4b31adacf79, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ec2e2e8b868ab96f2aa57ffdbc46b33cb7916f94 && git checkout ec2e2e8b868ab96f2aa57ffdbc46b33cb7916f94
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin e357a441c6423798a673d4a39ecee4b31adacf79 62ca3debd456b4b313fa21c4c3e9e2b0968b76f1 && git checkout -B drift-repro e357a441c6423798a673d4a39ecee4b31adacf79 && git merge --no-ff 62ca3debd456b4b313fa21c4c3e9e2b0968b76f1

node scripts/docs-audit/affected-docs.mjs --json e357a441c6423798a673d4a39ecee4b31adacf79

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs e357a441c6423798a673d4a39ecee4b31adacf79 → pass the list as
args.docs, on the commit named under Which tree this was computed on.