feat: wire /manifests/cloudflare into scaffold_create — docs-to-decks parity with Stackbilder web

[stackbilt-admin]

Context

Stackbilder web currently calls `GET /manifests/cloudflare` on the TarotScript worker and uses
those facts (live Cloudflare docs-derived model catalog, availability, limits) in the scaffold flow.

The MCP gateway's `scaffold_create` does not call this endpoint. It goes through
`POST /run` with the `scaffold-cast` spread → `stackbilt-engine /scaffold`. Cloudflare
docs-to-decks facts are not in the MCP tool contract today.

This means MCP callers (Claude Code, external MCP clients) are getting scaffold output built from
baked-in deck snapshots while Stackbilder web users get live docs-backed facts.

What's needed

Wire `GET /manifests/cloudflare` into `scaffold_create` in `proxyRestToolCall` so the
manifest facts are merged into the scaffold output (or passed as context to the engine call).

Likely shape:

1. Call `/manifests/cloudflare` in parallel with the existing `/run` + engine calls
2. Merge manifest facts (model catalog, limits, availability) into the `scaffold_create` response

Dependency

TarotScript team is implementing the docs-to-decks ingestion pipeline (tarotscript#374). This
issue is blocked until that work lands and the manifest endpoint stabilises. Wire up after
TarotScript ships.

Reference

• TarotScript endpoint: `GET /manifests/cloudflare` (live on tarotscript-worker)
• Stackbilder web integration: existing — this is the parity gap
• Gateway handler: `src/gateway.ts` → `proxyRestToolCall` → `scaffold_create` branch

[stackbilt-admin]

Blocked on tarotscript#374 (docs-to-decks ingestion pipeline). Once that lands and GET /manifests/cloudflare stabilises, the gateway-side change is a parallel fetch in proxyRestToolCall's scaffold_create branch + merge into the response. Keeping open until TarotScript ships.