fix(cp): make pdbFetch throw instead of returning null

[netravnen]

pdbFetch resolved to null for every failure mode -- HTTP error, JSON parse
failure, transport error and timeout alike. Because null is also a
plausible "nothing here" value, that silently turned the error handling
written around it into dead code.

fetchRecentNetixlanChanges shows the cost. Its first try block always
reached its return, so both its catch and the entire client-side filtering
fallback beneath it were unreachable. A rejected updated__gte filter
therefore reported "0 rows, no error" -- an admin verifying an IXLAN
renumber would read that as "nothing changed" rather than "the check did
not run". The code was written expecting pdbFetch to throw; the null
return was the deviation, so this restores the surrounding design rather
than imposing a new one.

Changes:

• Added makePdbFetchError(url, detail), producing a PdbFetchError carrying
  name/status/url/detail so callers can branch on the failure rather than
  guess at it.
• All seven null exits (three same-origin, four cross-origin) now throw or
  reject. recordFetchFailure diagnostics are unchanged; the same-origin
  catch rethrows an existing PdbFetchError untouched so status and type
  survive.
• Reviewed all 21 call sites. Eighteen already had an enclosing catch that
  was dead code and is now live; each was read to confirm it does something
  sensible (they return error-carrying result objects).
• Three callers deliberately want a sentinel, so they catch at their own
  boundary and say why: requestJson (getBootstrap carries an explicit "@ai
  Preserve ... null-on-failure" contract for graceful RDAP degradation),
  and the GraphQL/REST network-name batch fetchers, whose null and []
  returns are fallback signals their paging loop depends on.
• Guarded the networkixlan toolbar's fire-and-forget void (async ...)(),
  which had no handler at all. A throw there would have become an unhandled
  rejection; the org/ix links are decorative, so a failed lookup now logs
  via dbg and omits them, matching prior behavior.
• Documented both rules in docs/CONVENTIONS.md.

Security:

• N/A directly, but it removes a class of silent failure in the flows that
  verify destructive work. The renumber verification report can no longer
  claim zero changes when it never successfully queried.

Testing:

• node --test from user.js/: 500 tests, 499 pass, 1 skipped (live tests are
  opt-in), up from 493/492.
• Added tests/cp-pdbfetch-errors.test.js covering the typed rejection and
  its status/url/detail, that success still resolves to a parsed payload,
  and that the revived fallback both runs and reports source
  "client-filter" -- a path that could not previously execute.
• Confirmed not vacuous: restoring the null return on HTTP error fails 6 of
  the 7 new cases.
• Re-audited every call site afterwards; none is left without a handler.

Backwards Compatibility:

• Behavior on success is identical.
• Behavior on failure changes by design: callers that previously saw null
  now see a rejection. Every site was inspected and either already handled
  it or was updated, so no caller observes a different outcome than before
  -- except fetchRecentNetixlanChanges, which now actually falls back.

Assisted-by: Claude:claude-opus-5

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}