fix(webhook): block SSRF to internal addresses in callback URL validation

[System625]

Summary

Closes #3. Webhook callback URL registration previously only checked that the
URL parsed and used http/https, letting an authenticated caller point the
indexer at internal services or cloud metadata endpoints (SSRF).

Changes

• Add src/utils/ssrfGuard.ts with assertCallbackUrlAllowed() — validates the
  scheme, resolves the host via DNS, and rejects any address in a
  loopback, link-local (incl. 169.254.169.254), RFC1918, CGNAT, or other
  reserved range (IPv4 and IPv6, including IPv4-mapped).
• Enforce the guard at registration time in indexerController.ts (returns
  400 on a blocked URL).
• Re-validate the resolved address at delivery time in webhookService.ts
  (postWebhook), defending against DNS rebinding on both initial dispatch and
  retries.
• Document the allowed/blocked policy in docs/webhook-url-policy.md.

Tests

• New src/utils/__tests__/ssrfGuard.test.ts covers 127.0.0.1,
  169.254.169.254, a 10.x host, IPv6, public addresses, and multi-address
  resolution.
• Existing webhook delivery tests mock the guard to avoid real DNS.
• npm test -- ssrfGuard webhookService → 33/33 passing; npm run lint → 0
  errors.

[ogazboiz]

SSRF guard is solid. DNS resolution at both registration and delivery time covers the DNS rebinding vector. Comprehensive IP range checks for IPv4 and IPv6 (including IPv4-mapped). Tests cover the key scenarios. Docs are clear. LGTM.

[ogazboiz]

This PR has been approved but has merge conflicts with the base branch. Please rebase your branch on the latest main and push to resolve the conflicts. Once clean, we can merge.

[System625]

Hi @ogazboiz I've rebased on the latest main and resolved the conflict in indexerController.ts. All good to merge

[ogazboiz]

re-confirming after your rebase: the SSRF guard is still solid (DNS resolution at both registration and delivery, full IPv4/IPv6 range checks incl IPv4-mapped) and the indexerController conflict resolution is clean. note: the repo's ci is currently red for reasons unrelated to your pr (a separate lint/typecheck/test mess on main from earlier bad merges, i'm cleaning it up separately) so i'm merging on the approved logic + mergeable state. thanks for the solid work.