docs: local-node SPA serving, local-first caching, omnibox + DIG toolbar

[MichaelTaylor3d]

Summary

Documents the extension's upcoming node-served reads (super-repo #289/#290/#291/#292, in progress in the dig-node + dig-chrome-extension lanes):

1. SPA .dig serving from a local node — with a local dig-node reachable, a chia:// store opens directly from it as an ordinary website: rooted at the store so relative + root-absolute links resolve within it, and an unmatched client-side route falls back to the store's entry page so single-page apps work. External absolute links are untouched. No reachable node → same address opens via the existing sandboxed viewer + public network, unchanged.
2. Local-first caching — a store syncs down on first open, then serves entirely from disk; the public network is used only until synced (or for evicted stores); a new on-chain version triggers a re-sync.
3. Omnibox dig keyword — type dig + a URN/chia:// address straight into the address bar.
4. On-page DIG toolbar — verified-on-chia + loaded-from-local indicators overlaid on node-served pages, opening the extension's fuller views.

Where

• docs/browser/chia-protocol.md — new "For integrating developers — serving from a local node" section (rooted paths, root-absolute reroot, SPA history-fallback, asset-miss stays 404, no-node fallback).
• docs/audiences/content-consumers.md — task-oriented coverage of the same capability + the omnibox + the toolbar; fixes stale content: the extension bullet previously said only dig-dns produces a real page for an opened address — corrected to reflect that a reachable node already does.
• docs/run-a-node/point-a-consumer.md — new "Local-first caching" section.
• docs/run-a-node/universal-installer.md — fixes the same stale dig-dns-only framing in the "Browse .dig names directly" section.
• Mirrored into all 13 locale copies (i18n/*/docusaurus-plugin-content-docs/current/...) per this repo's established mechanical-duplicate i18n policy (see e.g. 3dd099b) — English source, since a full per-language translation pass isn't feasible in this change. A follow-up localization pass is still needed for these new paragraphs (tracked as a natural follow-up, not blocking).
• static/knowledge-graph.json regenerated (npm run gen) to pick up the new cross-page links.
• No new pages were added, so llms.txt/sidebars.ts/sitemap generation needed no manual entries (sitemap is auto-generated at build time and already includes every existing page).

Version bump

Patch (0.3.19 → 0.3.20): docs-content-only change, no public-API or site-behavior change, per repo convention for docs commits.

Verification

• npm run build — green, all 14 locales build clean with onBrokenLinks/onBrokenAnchors: "throw" (this caught one cross-locale-unstable anchor I'd introduced — control-panel.md's "Reserve disk space" heading has no explicit {#id}, so its auto-slug differs per translated locale; fixed by linking to the page without the fragment).
• npm run typecheck — clean.
• npm run test:unit — 1/1 pass.
• npm run test:a11y — 22/22 pass (axe WCAG 2.2 AA, ARIA snapshots, keyboard nav, mobile nav — desktop + mobile).
• npm run test:e2e — 28/28 pass (adds SEO/meta + hreflang/sitemap checks on top of the a11y suite).
• Machine entry points present in dist/ (llms.txt, sitemap.xml, robots.txt).

Not merging

Per the task's single-writer docs lane instructions, opening this PR for review/CI but not merging — the dig-node and dig-chrome-extension implementation lanes for #289–#292 are still in progress in parallel.

Refs DIG-Network/dig_ecosystem#289
Refs DIG-Network/dig_ecosystem#290
Refs DIG-Network/dig_ecosystem#291
Refs DIG-Network/dig_ecosystem#292

🤖 Generated with Claude Code