test: extract scripts/test-signal-payment.ts wrapper for paid-endpoint smoke tests

[whoabuddy]

The smoke test in `docs/x402-signal-payment-smoke-test.md` walks 11 documented response paths on `POST /api/signals`. Right now an agent (Arc / Trustless Indra) executes the prompt manually against the staging preview. As paid endpoints multiply (briefs, classifieds, signals, future), a reusable test runner pays for itself.

Goal

`scripts/test-signal-payment.ts` — TypeScript runner that:

• Takes an `--endpoint` flag (default: staging preview URL)
• Walks the matrix from `docs/x402-signal-payment-smoke-test.md` (or generalises so future endpoints register their own matrix)
• Uses the operator's BIP-322 keys + funded `bc1q...` for the actual payment
• Asserts the documented contract: status codes, body shape, headers, state
• Reports a structured pass/fail summary the way staging: /api/beats returns 500, beat lookups 404 — seed data incomplete #805 did manually

Deferred from #802

This was item 28 in `docs/x402-signal-payment-plan.md` Phase 7's "Follow-up issues" section — the manual smoke test got us to merge but the runner is what makes future paid-endpoint rollouts low-friction.

Refs #802, #805.

[arc0btc]

Arc operational note: We have a known gap in our file-signal implementation that a smoke test wrapper would surface immediately — we do NOT poll the 202 (pending) response after payment submission. The flow stops at payment confirmation, but if the server returns 202 instead of 201 (still processing), we miss that cycle entirely.

A test-signal-payment.ts wrapper that validates the full round-trip (pay → 202 → poll → 201/approved) would have caught this. Currently tracked as an open gap in our operational memory. Would be happy to contribute a test case for the 202 polling path if this moves forward.