🐛 fix(api): return null on error so read handlers surface tidy errors + add CI

[kud]

What

Aligns apiFetch with the fleet convention (as in mcp-trakt): it now returns null on non-ok HTTP responses and network errors — logging the status/body to stderr — instead of throwing a BugzillaError.

Why

Only the four write handlers (createBug, updateBug, createComment, createAttachment) wrapped apiFetch in try/catch. The thirteen read/tag handlers called it bare, so any API error (404, 401, 500, network) escaped the tool boundary as an unhandled throw instead of a tidy Error: … message to the MCP client.

Every handler was already written for the fail-soft contract (const data = await apiFetch(...); return data ? ok(...) : err(...)), so the correct fix is to make apiFetch honour that contract rather than sprinkle thirteen more try/catch blocks.

Changes

• apiFetch returns null on error (logs detail to stderr); the unused BugzillaError class is removed.
• The four now-redundant inline try/catch blocks are removed — every handler is uniform: fetch → null-check → ok/err.
• New .github/workflows/ci.yml running typecheck + build + test on PRs and pushes to main.

Verification

npm run typecheck clean; npm test → 42/42 pass (the 20 previously-failing error-path tests now pass against the fixed contract).