[P7] Documentation site migration

[ChrisonSimtian]

Current state

The NUKE docs live at `nuke.build/docs`, source presumably in a separate repo (Docusaurus-based per CONTRIBUTING.md). We don't own that.

Action

1. Stand up a new docs site at the Fallout domain (P7.1) — use Docusaurus or VitePress or similar.
2. Port the existing `docs/` directory from this repo as a starting point.
3. Update all `nuke.build` references inside the docs themselves.
4. Inbound-link audit — anything that links to nuke.build/* now redirects somewhere we control? (Out of our control; that's nuke-build/nuke's docs.)

Out of scope

• New content beyond renames
• A glossy redesign

Done when

• Docs site live at `/docs`
• All inter-doc links work
• README links to the new docs site
• Search works (Algolia/etc.)

[ChrisonSimtian]

Cross-ref: #61 covers the emergency holding page on fallout.build (nuke.build went offline). This issue stays focused on the full docusaurus port — the bigger content+nav+search effort.

[ChrisonSimtian]

Direction note (from #61 discussion):

#61 will go with the minimal static approach (hand-written index.html on gh-pages) to get something up fast. The dogfooding story — using Fallout's own build system to produce the site — belongs here in #41 and we want to land it sooner rather than later.

Rationale: it's a credibility story (the build framework's own docs site is built by the framework), and it gives us a useful production-shaped test case for any docs-generation tooling we add. Holding-page HTML doesn't earn its keep as a dogfood target; a proper port does.

When #41 picks up, the natural shape is:

• Add BuildSite / PublishSite targets to build/Build.cs
• Pick a generator (docfx, docusaurus, statiq — open question, worth a separate design comment)
• New GitHub Actions workflow (or extend release.yml) to deploy generator output to gh-pages
• The static index.html from Put up an emergency holding page on fallout.build (GitHub Pages) #61 gets replaced by generator output — no wasted work