Add zero-to-hero wiki for the Gradle build system

[feldoh]

AI generated to help us try and understand this process better take with several buckets of salt. Only pushed here for sharing purposes.

Summary

Adds a 25-page wiki under docs/wiki/build-system/ that walks a contributor with no JetBrains-plugin or Gradle background up to "can confidently maintain and upgrade the build" — without comparing against unrelated JetBrains template repos every time something needs changing.

The motivation is the maintainer's stated pain: the Gradle upgrade was the second time they had to rework the build by pattern-matching against other JetBrains repos. The wiki targets that mental-model gap directly.

What's in it

Four parts, read in numeric order on first pass:

• Part 1 — Foundation (§01–§05): conceptual teaching only. What a Rider plugin is, the two-tier mental model (JVM frontend + .NET backend talking over RD), just-enough-Gradle, providers / configuration cache, and the cast of tools.
• Part 2 — This project (§06–§17): tied to actual file:line in the repo. Repo tour, version-pinning map (the most-consulted page), an annotated walkthrough of build.gradle.kts, the :protocol subproject + rdgen, the .NET side, the dual-csproj pattern, the riderModel bridge, the prepareSandbox glue, runIde + debugging, CI/publishing, and a quirks-and-known-issues ledger.
• Part 3 — Operate (§18–§19): day-to-day recipes (run locally, bump version, add a .NET dep, add an RPC, publish a release, etc.) and version-bump runbooks (Gradle, IPGP, rdgen/Rider SDK, Kotlin, JDK, .NET SDK).
• Part 4 — Reference (§20–§24): mermaid task graph + file-flow + version-pinning diagrams, a contributed-tasks table (who adds prepareSandbox, runIde, etc.), a glossary, where to ask JetBrains for help, and a refactor backlog.

Pages are tagged with audience signals (Foundation / This Project / Operate / Reference) and each Part 2 page leads with whether the topic is the same as IntelliJ plugins, unique to Rider, or a custom local workaround — so a reader from an IntelliJ background isn't blindsided.

Why this shape

It's a graduated learning journey, not a reference dump. Every page assumes only what came before. The verification target on the homepage is: a stranger to both Gradle and JetBrains plugins should be able to clone, install prereqs, run ./gradlew runIde, and see the example mod open in a sandboxed Rider — using only §00 + §01–§06 + §18 — in under 90 minutes.

Part 4's refactor backlog (§24) ties the maintainer's stated goals to concrete file:line edits: consolidate version pinning into libs.versions.toml, kill the legacy PowerShell scripts (CI doesn't use them), convert the Exec-based dotnet tasks to typed Kotlin task classes in buildSrc/, fix the ${buildDir} deprecation before Gradle 10, etc. These are captured for the maintainer to pick from, not committed-to action.

The wiki is documentation only — it doesn't change any build behaviour. Refactors are intentionally a follow-up so reviewers can read the docs without also reviewing build changes.

Test plan

• Read §00, §01, §02 cold and confirm the two-tier mental model lands in one paragraph
• Read §07 and verify every version-pinning entry against the actual file (drift between gradle.properties:27 and build.gradle.kts:10 is the headline finding)
• Read §09 with build.gradle.kts open beside it; every block in the file should have an answer in the page
• Read §14 and walk through the prepareSandbox block top-to-bottom to confirm the explanation matches the code
• Read §19 and confirm a Rider SDK bump runbook lists every file that actually needs editing
• Spot-check §17 callouts against the codebase (e.g. confirm riderBaseVersion in gradle.properties:28 really has zero references)
• If you have a fresh-clone machine handy: follow §18's "Run the plugin locally" recipe end-to-end and report any missing prerequisite

🤖 Generated with Claude Code