epic: one execution topology, and it is the wrong one for serverless

Why

FlexiQ has exactly one execution topology: a long-lived process that connects in and stays
connected. Embedded, it is the worker in the application. In server mode, it is an executor that
dials the attach listener or the flexiq.executor.v1 stream and holds it open.

That topology cannot run on a platform where processes are started by an inbound request and
billed for the time they are awake. Cloud Run, Lambda, Azure Functions and Cloudflare Workers
are all shaped the other way round: something calls them. A user on any of those platforms
cannot use FlexiQ at all without keeping a container up purely to hold a socket open — which is
the cost the platform was chosen to avoid.

The inversion is a dispatch target that dials out. Once the scheduler can call an HTTP endpoint
per job, every serverless platform is an adapter and a docs page, not a feature.

Shape

• HttpDispatchTarget — a dispatch target beside the attach path. The scheduler dials out
  per job.
• Outbound auth and an SSRF allowlist — the scheduler making arbitrary outbound requests
  with a payload is a request-forgery primitive unless it is constrained by construction.
• A Settle callback — return 202, run past the request deadline, report the outcome later
  under the lease. This is what makes the Cloud Run 60-minute and Lambda 15-minute ceilings stop
  mattering.
• Cancellation in push mode — cancel is a headline differentiator today and the naive push
  design loses it.
• Triggers — HTTP, object-store event and cron as enqueue sources, so the server is a hub
  and not only a sink.
• Event egress — lifecycle events out to CloudEvents, Kafka, NATS or Redis Streams, so
  others can build on job events without touching this code.

What this is not

Not a rewrite of the pull path. Attach stays the default and stays the better answer for a
long-lived worker: it keeps the lease local, it makes cancellation trivial, and it does not put
a load balancer between the scheduler and the work. Push is additive.

Not four platform integrations. One dispatch target, correctly built, plus documentation
per platform. A named "Lambda feature" is a maintenance liability with a vendor's release
cadence attached.

Not a place to be clever about fencing. The (owner, attempt, epoch) fence and the lease
token from #719 are what make a late Settle safe. Reuse them exactly.

Start by reading the existing attach path and the lease and fencing design from #719. Define how the proposed HttpDispatchTarget, Settle callback, cancellation, triggers, and event egress fit the existing scheduler without rewriting pull mode; done means the design is implemented and documented for serverless deployment.