refactor(server): make a refusal its own HTTP response

[kstonekuan]

MediaResolutionError and SidecarError subclassed plain Exception and carried a status and detail that something else had to convert into an HTTPException — two converter functions, plus a catch-and-re-raise at all six call sites that did nothing but copy two fields.

Subclassing HTTPException instead makes the refusal be the response. Raised from anywhere under a route, FastAPI renders it with the status and detail the raising module chose, so both converters and every rewrap go.

52 deletions, 30 insertions — 2,708 → 2,679 code lines.

They stay two types rather than collapsing into one shared refusal, because _media.is_uri_servable catches media refusals specifically; a single shared type would let it swallow an unrelated refusal raised nearby.

Verification

Behaviour is unchanged and checked rather than assumed:

• The OpenAPI schema dumps byte-identical before and after.
• Every status assertion in the media, sidecar and pin suites still passes — 645 tests, ruff and ty clean.

Provenance

This came out of an audit asking whether hflow-server earns its lines, after the question "why do we need so many files for the server". The honest answer was mostly that it does: across three independent deletion theses, each adversarially attacked with claims re-verified on a clean copy, ~1% of the code was signed off as safely deletable, and the file count was explicitly not the problem. This is that 1%.

Two of the rejected items are worth recording, since both reviewers that proposed them had them wrong: the claim that these classes already subclassed HTTPException (they did not — hence the __init__s were load-bearing), and a claim that a committed React bundle sat in the wheel (a real bug at the time, fixed separately in #116 before this ran).

🤖 Generated with Claude Code