Swarm probe polls its full 5-minute budget on permanently-missing paths

[meinharrd]

Follow-up to #173 (and the underlying design noted in #172).

Problem

The navigation probe cannot distinguish "content not yet retrievable because the Bee node is still warming up" from "this path permanently does not exist" — Bee returns 404 in both cases. So a navigation to a path that will never resolve (e.g. a typo like bzz://<hash>/nope.html, or a stale link into a re-uploaded site) polls HEAD /bzz/<hash>/nope.html for the full 5-minute overall budget before landing on the "Swarm content not found" page.

This is not a regression from #173 — the same ambiguity always existed for bare-hash probes — but #173 moves it to the path level, where typos and stale deep links make the permanent-404 case more likely in practice.

Possible directions

• If the manifest root (HEAD /bzz/<hash> or the manifest chunk itself) becomes retrievable while the probed path still 404s, the manifest is demonstrably resolvable and the path is genuinely absent — fail fast with a proper 404 page instead of polling out the budget. (Caveat: index-less manifests 404 on the root forever, which is exactly the bzz:// deep links fail: navigation probe HEADs the bare hash, 404s forever on manifests without a root index document #172 case, so the signal would need to come from something like /bytes/<hash> or a manifest traversal rather than the root /bzz lookup.)\n- Check whether Bee's 404 response bodies/headers distinguish "reference unresolvable" from "path not found in manifest" and branch on that.\n- Shorten the budget or surface a "still looking — the content may not exist" state with a cancel affordance once the node is demonstrably warm (peers connected, other lookups succeeding).

Relevant code

• src/main/swarm/swarm-probe.js — 404/500 are treated as "keep polling" with DEFAULT_OVERALL_TIMEOUT_MS = 5 min