[factory] Refuse dispatch when the workspace is over budget

[khaliqgant]

Problem

Nothing consults spend before spawning. relayburn ledgers cost after the
fact and burn mcp-server exposes it read-only and advisory, so a stuck recipe
burns until a human notices. Factory has a safety gate for what it may work
on and no gate for how much that may cost.

Fix

Two halves. The second only works if the first lands.

1. Attribution

Stamp every agent Factory spawns with the burn enrichment tags that already
exist:

• workflowId = the dispatch lifecycle runId
• tag issue=<workUnitId>
• tag repo=<slug>

Without this, spend cannot be attributed to a run and any budget number is a
guess. With it, burn hotspots --workflow <runId> answers "what did this issue
cost" directly, and burn summary --group-by-tag repo answers it per
repository.

2. The gate

Add a budget block to factory.config.json, alongside safety and resolved
nearest-first the same way:

"budget": {
  "source": "burn-cloud",
  "window": "24h",
  "maxUsd": 40,
  "onExceeded": "refuse"    // "warn" to log only
}

Evaluate it in the src/safety/ path where scope is already evaluated, so a
refusal lands in the existing skipped: Array<{ issue, reason }> channel on
IterationReport (src/types.ts:169) and surfaces through factory status and
the Slack thread instead of crashing a run.

The read is GET /v1/summary?since=<window> against burn-cloud with the
brn_at_* token.

Behavior:

• No budget block → no gate, unchanged behavior.
• Over maxUsd with onExceeded: "refuse" → every ready issue is skipped with
  reason budget exceeded: $X of $Y in <window>.
• burn-cloud unreachable → refuse. A dispatch gate fails closed.

What this is not

/v1/summary is scoped by org, model, and machine, and burn-cloud has no
reservation concept. N concurrent dispatches can each pass the check and
collectively overshoot by up to N runs. This is a coarse circuit breaker, not an
atomic per-run debit.

Making it atomic means burn-cloud grows POST /v1/reserve plus
commit-on-completion. That is a burn-cloud change, not a Factory one, and is
worth filing only if the circuit breaker proves insufficient in practice.

Definition of done

• Agents spawned by a dispatch carry that dispatch's workflowId and the
  issue / repo tags; burn hotspots --workflow <runId> returns its spend.
• A workspace over maxUsd reports ready issues as skipped with the budget
  reason rather than dispatching them.
• burn-cloud unreachable refuses rather than dispatching.
• Absent budget config produces no behavior change.

[khaliqgant]

A per-run cost ledger already exists in cloud, which simplifies this issue
substantially and removes the proposed burn-cloud dependency.

AgentWorkforce/cloud@cee1b81e9 — feat(factory): surface per-run cost ledger
(#2817) — added:

• packages/web/lib/factory/telemetry-contract.ts
• packages/web/lib/factory/telemetry-store.ts
• per-run cost surfaced on the Factory dashboard

So Factory already reports per-run cost to cloud over the existing reporting
channel (src/config/schema.ts, reportingSchema — "Authenticated run progress
is a Cloud product feature").

Revised plan:

Part 1 (attribution) is largely done. Cost is already attributed per run in
cloud. What remains is verifying the run identity it reports under matches the
work-unit key from #211, so spend attributes to the work unit rather than to a
surface-local key. Stamping burn tags stays worthwhile for local causal
attribution (burn hotspots --workflow), but it is no longer the prerequisite.

Part 2 (the gate) should read cloud, not burn-cloud. Factory already holds an
authenticated cloud channel; adding a second backend for the same question is
avoidable. Replace the proposed "source": "burn-cloud" with a read against the
existing Factory telemetry store, keeping the rest of the config shape and the
fail-closed semantics unchanged:

"budget": {
  "source": "cloud",
  "window": "24h",
  "maxUsd": 40,
  "onExceeded": "refuse"
}

The concurrency caveat is unchanged and possibly worse. The cloud ledger is
a reporting sink with ingest lag, so a budget read can be staler than a
burn-cloud read. This remains a coarse circuit breaker. An atomic per-run debit
still requires a reserve/commit endpoint — now a factory_runs concern in cloud
rather than a burn-cloud one.