Expose a request-free runtime accessor for queue and scheduled handlers (withEmDashRuntime)

[swissky]

Problem

Issue #1887 describes a gap: there is no supported way for a request-free handler (a Cloudflare Queue consumer, a custom scheduled() handler) to reach the EmDash runtime and invoke a plugin route.

The common pattern is to move slow work out of a content hook into a queue — but the consumer then needs to call back into the plugin (plugin storage, ctx.media.upload, ctx.content.update) to finish the job, and handlePluginApiRoute is only reachable through locals.emdash on a real HTTP request. The SELF.fetch() workaround fails too: a cookieless self-request gets the limited locals.emdash without handlePluginApiRoute.

Proposal

Export a small request-free accessor from emdash/middleware, built on the exact plumbing runScheduledTasks (plugin cron) already uses:

export async function withEmDashRuntime<T>(
	run: (runtime: EmDashRuntime) => T | Promise<T>,
): Promise<T>;

Usage from a queue consumer:

import { withEmDashRuntime } from "emdash/middleware";

async function queue(batch: MessageBatch) {
	await withEmDashRuntime(async (runtime) => {
		for (const message of batch.messages) {
			await runtime.handlePluginApiRoute("my-plugin", "POST", "/finishJob", request);
		}
	});
}

Design points:

• Not a new mechanism. It reuses the internal getConfig() → getRuntime() → createRequestScopedDb() → runWithContext() path that powers the Cron Trigger sweep, refactored into a shared helper. Connection-backed adapters (Postgres over Hyperdrive) get an event-scoped connection that is committed and closed after the callback; stateless adapters (D1, Node SQLite) use the singleton as before.
• Trusted, server-only. The callback gets the raw runtime with no auth/CSRF checks — the same trust level plugin cron already has. Documented accordingly.
• isWrite: true for the event scope, so queue jobs route to the primary.

I have a working implementation with tests and docs; opening a PR referencing this discussion and #1887.