Add run-scoped public base URLs

[midagedev]

Summary

One Billtap server shared by several proxied CI stacks could only generate absolute URLs (checkout session.url, billing portal URLs) against the single global BILLTAP_PUBLIC_BASE_URL. In multi-job CI each stack has its own nginx origin (e.g. https://localhost:19029/billtap), so hosted checkout redirects pointed at https://localhost:8080 where nothing listens — ERR_CONNECTION_REFUSED and 24 cascading checkout/lifecycle test failures.

Each run can now pin its own browser-facing base:

curl -X POST http://billtap:8080/runs/<runId>/v1/config \
  -d public_base_url=https://localhost:19029 \
  -d public_base_path=/billtap

Absolute URLs generated under that run resolve their base in order:

1. The run's configured public_base_url (+ optional public_base_path)
2. An explicit X-Billtap-Public-Base-Url request header
3. The forwarded proxy origin (X-Forwarded-Proto/Host/Prefix) for run-scoped requests
4. The global BILLTAP_PUBLIC_BASE_URL, then the request host — the previous behaviour, so the default run and single-stack setups are unchanged

The setting lives in memory with the run's per-run API handler (same lifetime as idempotency keys) and is dropped on run deletion. GET/DELETE /runs/<runId>/v1/config inspect and clear it; the first request lazily creates the run, so a seed container can configure it before seeding. Caller-provided success_url/cancel_url values are never rewritten.

Verification

• go test ./... passes; all pre-existing tests pass unchanged (global-env fallback intact)
• New server tests: per-run bases isolate (run-a vs run-b vs unconfigured run vs default run), hosted-page session refetch sees the run base, run cleanup drops the config, forwarded origin beats the global base only for run-scoped requests, run config beats the forwarded origin
• New API tests: config endpoint roundtrip (set/inspect/clear, /api/config alias), validation rejects non-http(s)/query/credential bases and public_base_path without public_base_url, header override works and loses to run config, success_url/cancel_url untouched

Open risks

• The per-run base is in-memory: a server restart loses it while run DBs persist. CI seeds it at job start, so this matches the existing in-memory idempotency-store trade-off; a settings table can be added later if persistence is needed.

🤖 Generated with Claude Code