Generic per-repo preview-URL provider config (Cloudflare/Vercel/Netlify/manual template)

[JSONbored]

Part of #3607.

Motivation (reshaped from the original scope — see comments below)

The original scope was Cloudflare-Workers-Builds-specific (and effectively metagraphed-specific): teach
preview-url.ts to query Cloudflare's API for a branch/commit's build. That doesn't serve the actual goal —
any self-hoster should be able to wire up THEIR repo's existing preview-deploy setup with config, not
code, regardless of whether they use Cloudflare, Vercel, Netlify, or something bespoke.

Concretely: metagraphed-ui's Worker is connected to Cloudflare Workers Builds (Git integration, root dir
apps/ui, non-production-branch builds enabled — confirmed live in the dashboard). But a live check against
metagraphed PR #3724 found neither a "Workers Builds" GitHub check run nor a GitHub Deployment record for its
head SHA — Workers Builds' non-production output apparently doesn't surface on GitHub the way Cloudflare
Pages' classic integration does. Building bespoke code against ONE provider's API would just repeat this
problem for the next self-hoster using Vercel, Netlify, or anything else.

Requirements

• Design a review.visual.preview .gittensory.yml config block that lets a repo declare how to find its
  own "after" preview URL, supporting (in rough priority order):
  1. Manual URL template (universal fallback, zero provider knowledge needed): e.g.
     url_template: "https://pr-{number}.mysite.com" or "https://{head_sha_short}.myworker.workers.dev" —
     works for literally any provider whose preview URLs follow a predictable pattern, with no
     provider-specific code in gittensory at all.
  2. GitHub-native discovery (today's existing three methods — Deployments API, commit checks, bot PR
     comment) as the zero-config default for providers that DO integrate with GitHub the classic way
     (Cloudflare Pages, Netlify, Vercel's GitHub App all post real Deployments).
  3. (Stretch, only if 1–2 don't cover a real case) a provider-specific API lookup — e.g. Cloudflare Workers
     Builds' own API if its dashboard has no "post to GitHub" toggle. Investigate whether such a toggle
     exists before writing provider-specific code — a config setting is more maintainable than an API client.
• Precedence: an explicit url_template always wins (repo told us exactly where to look); otherwise fall
  back to GitHub-native discovery; otherwise no preview available → existing pending/failed placeholder
  behavior, unchanged.
• Absent config must be byte-identical to today (GitHub-native discovery only, exactly gittensory-ui's
  current behavior) — this is additive, not a breaking change for existing behavior.
• Whatever's built must let metagraphed use option 1 (manual template) immediately without needing option 3
  at all, since Cloudflare Workers Builds' GitHub-visibility gap may never get resolved on Cloudflare's side.

Deliverables

• .gittensory.yml schema + parser + resolver for review.visual.preview (config-as-code pattern:
  yml > default, parser in focus-manifest.ts, resolver, tests)
• preview-url.ts tries: explicit template → existing GitHub-native discovery → pending/failed as today
• Written finding on Cloudflare Workers Builds' actual GitHub-visibility behavior (kept for the record,
  even though the shipped fix doesn't depend on it)
• Test: templated URL resolves correctly (including {number}/{head_sha}/{head_sha_short}
  placeholder substitution), absent config falls through to existing discovery unchanged
• .gittensory.yml.example documents the new knob with a generic (non-metagraphed-specific) example,
  and metagraphed's own private config gets a real url_template set as the first real usage

Expected outcome

Any self-hoster can point gittensory at their repo's existing preview-deploy URL pattern with a few lines
of YAML, regardless of which provider they use — no gittensory code change required per provider.

Effort

S–M — the manual-template path is small and provider-agnostic; GitHub-native discovery already exists and
just needs to become the fallback instead of the only path.

[linear-code]

JSO-2817