Add a public API for programmatic workflow admission

[FredKSchott]

Problem

Flue has a public dispatch(...) API for asynchronously submitting input to a created agent from application-owned code, but there is no equivalent public API for starting a workflow run.

Application code such as app.ts, cloudflare.ts, queue consumers, cron handlers, and other trusted host integrations currently has two unsatisfactory choices:

• submit an in-process HTTP request to the mounted POST /workflows/<name> route; or
• import the workflow module and call run(...) directly.

The HTTP approach couples internal application code to route exposure, mount paths, request construction, and route authentication. Calling run(...) directly is not a valid substitute because it bypasses workflow admission, run identity and persistence, events and streaming, route middleware, and run inspection.

This is especially visible when documenting scheduled work. A Cloudflare scheduled() handler can call dispatch(...) directly for an agent, but starting a workflow requires routing back through the application HTTP surface. The same issue applies to an in-process Node scheduler.

Missing functionality

Flue should expose a supported public runtime API for application-owned code to admit a discovered workflow programmatically while preserving the normal workflow-run lifecycle. It should occupy the same conceptual role for workflows that dispatch(...) occupies for agents, without requiring callers to know generated runtime internals or synthesize HTTP requests.

The exact API shape is intentionally left open. The important contract is that programmatic invocation creates a real workflow run with the same identity, persistence, events, streaming, inspection, and target-specific behavior as ordinary workflow admission.

Relevant contexts

• Cloudflare Cron Triggers in src/cloudflare.ts
• Node schedulers in src/app.ts
• queue and email handlers
• application-owned Hono routes
• trusted internal integrations that need to start finite background work

Generated helpers under @flue/runtime/internal and direct workflow Durable Object access should not become the user-facing workaround.