feat(cf): per-package worker targeting for cf.worker.deploy / preview / cleanup — multi-worker consumer repos

[gingur]

Context

cf.worker.deploy.yml, cf.worker.preview.yml, and cf.worker.preview.cleanup.yml assume one worker per repo: a single root wrangler.toml, wrangler --env from the repo root. Upcoming product repos break that: looksfine (ingest worker + heartbeat DOs + status pages), docpipe (API + render pipeline) — multiple workers in one pnpm workspace.

Ask

Per-package worker targeting across the deploy / preview / cleanup trio:

• A way to point a call at one worker within the repo — likely a workingDirectory-style input (camelCase per naming standards) honored by every wrangler invocation; a consumer with N workers calls the reusable workflow N times (matrix or repeated jobs at the caller), keeping each reusable invocation single-worker and thin.
• Previews per worker: decide and document the masked-URL shape for multi-worker PRs (e.g. pr-<N>.<domain> for the primary worker, pr-<N>-<worker>.<domain> for siblings) and make cleanup tear down all of a PR's preview workers + domains.
• Production deploy sticky comment: when several workers deploy from one push, the version comment on the source PR should aggregate rather than spam (one comment listing each worker's version).
• Single-worker consumers unchanged — omitted input = today's behavior, no caller edits.
• Named-environment wrangler.toml convention ([env.production]/[env.preview]) stays per-package; document the multi-worker consumer recipe in README.

Sequencing

Independent of #92's toolchain, but there is no consumer to verify against until a product repo (looksfine or docpipe) has two workers. Planning may proceed when assigned; implementation should verify against the first real multi-worker consumer rather than a synthetic fixture if one exists by then.

Acceptance criteria

• One repo can deploy/preview/clean up N workers via N thin caller invocations; each PR's preview surfaces N URLs and cleanup removes all N.
• A today-style single-worker consumer runs byte-identical with no caller change.
• README gains the multi-worker recipe (caller matrix example + URL shape + permissions).