fix: make server.registerOperation() from components reachable via the ops API (#1736)

[kriszyp]

Fixes #1736.

Problem

server.registerOperation() from a component's resources.js (or Plugin API handleApplication) — the standard, documented pattern — was permanently unreachable via the ops API. Components load per worker thread, so the registration lands in that worker's module-local OPERATION_FUNCTION_MAP; the ops-API HTTP dispatcher runs only on the main thread and reads the main thread's own instance of that map. Every caller, including super_user, got 400 "Operation '<name>' not found". Only the deprecated startOnMainThread extension hook worked.

Fix: a cross-thread bridge (server/serverHelpers/registeredOperations.ts)

Mirrors the existing RESOURCE_OPENAPI ITC request/response pattern, with one deliberate difference: executing an operation is side-effecting, so a request is forwarded to exactly one registering worker — never broadcast-first-wins.

• Announce: a worker-side registerOperation() still sets its local map, then broadcasts OPERATION_REGISTERED; the main thread records name → Set<threadId>.
• Forward on miss: when main-thread dispatch misses its local map, it checks the registry and forwards the request body (OPERATION_EXECUTE_REQUEST) to one live registering worker — rotating across workers, pruning dead ids — and awaits the requestId-correlated response. Unknown names still fail fast with 400 (the registry gates forwarding, so no timeout is paid for genuinely unknown operations).
• Auth runs on the worker: the main thread authenticates and forwards the resolved hdb_user; the worker executes through the normal chooseOperation (full verifyPerms, where the operation function and its metadata actually exist) + processLocalTransaction. Workers never re-forward, so an unknown op can't loop. bypass_auth is re-stripped on the worker as defense-in-depth, and response correlation verifies the responding thread is the one the request was sent to.
• Failure handling: worker death mid-flight rejects in-flight forwards with 503 and forgets that worker's registrations (onThreadExit hook added to manageThreads); a wedged worker is bounded by the ops-API network timeout; structured-clone failures report a clear error in both directions instead of an opaque hang.

This fixes both component contexts named in the issue investigation (jsResource and handleApplication) at the registerOperation layer, and as a side effect lets server.operation() on the main thread reach component-registered operations too. Worker-local calls (server.operation() in a worker) are untouched — they hit the local map as before.

Explicitly out of scope (follow-up: #1742)

• Streaming results: a forwarded op returning a Readable gets an explicit 501 rather than an opaque failure (needs MessagePort transfer plumbing).
• isJob: was already ignored by registerOperation() before this change (never wired to job_operation_function); unchanged.

Testing

• New integration suite integrationTests/components/registered-operation.test.ts (fixture registers ops from resources.js, 2 worker threads): reachable via ops API with worker-side execution and forwarded user identity; repeated calls; error statusCode propagation (422); stream → explicit 501; unknown op → fast 400. 5/5 pass.
• Regression smoke: authentication, delete, job-queue (97/97), components.test.mjs (25/25).
• Build, oxlint, prettier clean.

Cross-model review (thorough: Gemini + Codex + domain pass)

No confirmed blockers. Adjudicated notes for reviewers:

• Rolling-restart window (significant, accepted): a draining worker stays in the registry until its port closes, so a fresh forwarded op can land on a worker that's shutting down. If the worker exits mid-execution the forward rejects with 503 rather than hanging — the residual exposure (op partially executes, then 503) is inherent to any worker-crash window, not new to this path.
• Post-deploy registration race (accepted): the announce is fire-and-forget, so a call arriving in the instant between component load and the main thread recording the announcement gets a transient not found — eventual-consistency window matching component load semantics generally.
• Response correlation now includes an originator check (defense-in-depth, adopted from review).

🤖 Generated with Claude Code

— KrAIs (Claude Opus 4.8), for Kris

[gemini-code-assist]

Code Review

This pull request implements a cross-thread bridge for server.registerOperation(), allowing operations registered on worker threads to be reachable by the main-thread ops-API dispatcher. The feedback identifies two key issues: a potential infinite recursion bug in executeRemoteOperation due to parameter shadowing of the Promise resolve/reject functions, and an overly restrictive deletion of body.bypass_auth on the worker thread that could break legitimate internal use cases.

[claude]

Reviewed; no blockers found.

[cb1kenobi]

Human and AI reviewed. No issues, neat feature!