v0.5.2 — never trapped on the loading screen

Codemble v0.5.2 — never trapped on the loading screen

Reported from a real run: parsing a JavaScript/TypeScript project, the loading
screen froze on "Lost contact with the local server (Failed to fetch)", and
clicking Cancel and pick another project did nothing. There was no way back
to the picker, and no way to reach the galaxy. The only exit was killing the
tab.

This patch makes that state recoverable. No new features, no breaking changes:
the CLI, the graph/checks API, and the on-disk progress format are unchanged.

Fixed

The escape hatch no longer depends on the server it is escaping

resetProject awaited the server's reset call before doing any local
teardown, and that await was deliberately left uncaught. When the local server
was unreachable, the request rejected, so the code that stops the progress poll
and returns the learner to the picker never ran at all.

The local teardown no longer waits on the server answering:

• A reset the server actively refuses (a real HTTP status) still stays put
  and reports inline — the project genuinely is still bound there, and
  blanking the app would desync from it.
• A reset that never reached a server releases the learner locally and says
  so, because there is no bound project left to disagree with.

The loading screen stops over-reassuring

A single failed poll still says the parse may be running fine — a brief hiccup
really may be nothing. But after eight consecutive failures (about eighteen
seconds with no answer) the screen now says what it actually knows: the local
server has not responded and may have stopped, and it points at cancelling and
running codemble again. It keeps retrying either way.

A load failure with no server on the other end now names the local server and
what to do about it, instead of surfacing the browser's bare "Failed to fetch".

Honest limits

The underlying reason a local server became unreachable mid-parse was not
reproduced — repeated parses of the reported projects, and repeated runs through
the real server and picker flow, all completed cleanly. This release makes that
state visible and recoverable rather than fatal; it does not claim to have
removed its cause.

Two tree-sitter segfaults observed while investigating were traced to a separate
tool running in the background on the same machine, not to Codemble's parser.