An address Hatchdoor does not recognise answers with a blank pane or a bare 404

[BattermanZ]

This was generated by AI during triage.

Hatchdoor has no answer for an address it does not recognise. Depending on how the visitor arrived, they get either a blank pane with no explanation or a bare browser 404, and the two are inconsistent with each other.

Found while triaging #293, which is where the blank pane first turned up. It is not a link problem. Markdown-style links were only one of several ways to reach it.

What happens

The browser app knows five addresses: the workspace root, /stats, /graph, /settings, and a note at /v/<vault>/n/<slug>. There is no route for anything else, and React Router renders nothing when no route matches. The sidebar, the explorer and the top chrome all render normally, so the result reads as a note that failed to load rather than an address that does not exist. Nothing is shown and nothing is logged.

The server registers the app's index for exactly those same five paths and serves everything else from the built static directory, which 404s when no such file exists. So the same address produces two different outcomes:

how the visitor arrives	what they get
client-side navigation, or a reload with the service worker active	the app, with an empty main pane and no message
a cold load with no service worker	a bare 404 from the static file server, no app at all

The service worker's navigation fallback is what splits these: it serves the cached index for any navigation outside its /api, /vault-assets and /health denylist, so a returning visitor lands in the app and a first-time visitor does not.

How to reach it

Against just dev-start, any address outside the five: /nope, /setting (a typo for /settings), or a note route carrying a slash inside the slug, /v/<vault>/n/20-projects/Beacon%20Launch.md.

In ordinary use it is reached by a mistyped URL, a bookmark from before a note was renamed, a shared link into a vault that has since been disconnected, and any in-note link whose href is not a note address (#293).

What already works

A note route whose slug names no note is handled: the note view says Note not found: <slug>. Only an address matching no route at all is silent. The fix is about the gap around that, not a replacement for it.

[BattermanZ]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Give Hatchdoor a not-found answer for an address it does not recognise, in both the browser app and the server, instead of a blank pane or a bare 404

Current behavior:
The browser app's route table covers the workspace root, the statistics page, the graph page, the settings page and a single-segment note route. Nothing matches any other address, and the router renders nothing when nothing matches, so the main pane is empty while the rest of the chrome renders normally. No message, no log line.

The server registers the app's index for that same set of paths and falls through to serving the built static directory, which answers a missing file with a bare 404. The service worker's navigation fallback masks this for a visitor who already has it installed, so the same address answers differently depending on the visitor's cache state.

Desired behavior:
An address Hatchdoor does not recognise produces one consistent answer: the app loads and its main pane states that the address is not a page, with a way back to the workspace. This holds for a cold load as much as for a client-side navigation.

A note route whose slug names no note keeps the note view's existing not-found message. That case is already handled and is not what this changes.

Key interfaces:

• The browser route table gains a catch-all matching every address the named routes do not, rendering a not-found state.
• StateBlock is the existing full-pane presentation for a title and a description; EmptyState, ZeroVaultState and BrokenStartState are its current users and set the pattern to follow.
• The server's SPA index route set and its static-file fallback decide which requests reach the app at all. An unrecognised address must reach the app rather than the static file server, while genuine asset, API and health paths must keep their current answers, including their 404s.
• The service worker's navigation fallback denylist already names the path prefixes that must never be served the cached index. Whatever the server does has to agree with that list rather than contradict it.

Acceptance criteria:

• An address matching no route renders a not-found state in the main pane, never an empty pane
• The state says plainly that the address is not a page and offers a way back to the workspace root
• A cold load of an unrecognised address, with no service worker, reaches the app and shows the same state rather than a static-file 404
• Requests under the API, vault-asset and health prefixes keep their existing responses, 404s included, and are never answered with the app index
• Every existing route keeps its current behavior, including the registry-recovery redirects and the demo-mode settings redirect
• A note route whose slug names no note still shows the note view's own not-found message
• The not-found state reveals nothing about whether a vault or a note exists
• Tests cover an unmatched address rendering the not-found state, and the server answering an unmatched address with the app rather than a static-file 404

Out of scope:

• Any change to how in-note links are classified, resolved or rewritten (Markdown-style links to notes are never resolved: full reload, then a dead end #293)
• Redirecting an unrecognised address to the workspace root instead of stating what happened
• Guessing what the visitor meant, or suggesting near-miss notes or pages
• Changing what the note view does when a slug names no note