fix(content): stop caching blank page bodies from transient GitHub failures

[bloxster]

Fixes the empty-body rendering reported in #720.

Note: the root cause written in the body of #720 is wrong — I retracted it in a comment there. This PR fixes the actual cause, described below.

The bug

getFileContentCached and getTranslationProbeCached both wrapped their whole body in catch { return null } and were registered with unstable_cache(..., { revalidate: false }).

revalidate: false means cache forever. So any single transient failure against the GitHub contents API — a 403/429 secondary rate limit, a 5xx, a network blip, a briefly expired token — resolved to null, and that null was then cached permanently under that path. Nothing ever revalidated it.

Downstream, src/app/[locale]/[...slug]/page.tsx cannot distinguish "fetch failed" from "page does not exist": at L497 a falsy markdown renders an MdxContainer with an empty body. The page returns HTTP 200 with the chrome and nav intact and nothing in the article — which is why it reads as a translation problem rather than a fetch problem, and why it reproduces identically in every locale.

The poisoning is not tied to any content change; it postdates feb0f033a and depends only on when a request happened to coincide with a GitHub failure.

The fix

Distinguish "the file is not there" from "we could not find out", and only ever cache the former.

• isMissing / rethrowIfTransient — a 404 is a real answer and null is correctly cached for it. Anything else rethrows, so unstable_cache stores nothing and the next request retries.
• decodeFileContent — getContent does not only return files. A directory returns an array; a blob over 1 MB returns encoding: "none" with empty content. The old Buffer.from(res.data?.content || "", "base64") turned both into "", indistinguishable from a missing page. These now throw and are logged instead of being silently cached as blank.
• Config faults throw instead of returning null. A missing OWNER/REPO is a deploy misconfiguration, not evidence the page is absent; returning null blanked every page requested during a misconfigured window.
• revalidate: 3600 on the content cache (probe cache already had 300). Bounds the damage of anything that still slips through.
• Cache keys include owner/repo/branch. These are closed over rather than passed as arguments, so without them entries written under one repo configuration are served after that configuration changes.
• Folder-scan fallback compares basenames exactly. The previous test also accepted normalize(file).includes(normalizedSlug), so ai-tools could resolve to AI_tools_for_offline.md and cache the wrong article's body under that path. Unrelated to the blank-page bug, but it is a wrong-content bug in the same function.

Risk

Throwing rather than returning null is the only behavioural change worth scrutiny. Every caller already wraps these in a catch that degrades to an empty render for that one request ([...slug]/page.tsx L440 and its outer try, api/content-md L63), and the route is force-dynamic, so no build path can abort on it. One recoverable empty render is strictly better than a permanently cached blank page.

Verification

Reviewed adversarially by GPT-5.5 and by a second model, both of which confirmed the mechanism and found no 500/build regression. Two findings from that review are folded in: config faults must throw (they previously contradicted the comment claiming every lookup returned a clean 404), and the cache keys needed the repo identifiers.

Not covered here, found during review and worth separate issues: getRootCached is awaited uncaught in wallets/page.tsx L49-51 and payment-processors/page.tsx L28-32, which can 500 those routes.