Decide and document the StarMap dependency pinning policy for code mods

[Maximilian-Nesslauer]

Problem

The netkans on main now carry three different StarMap dependency styles for code mods:

• 6 netkans pin exactly (min_version = max_version = "0.4.5"): AdvancedFlightComputer, AutoRemoveFinishedBurns, AutoStage, DeltaVMap, MeasureTools, StageInfo
• Compendium.netkan declares min_version: "0.4.5" only
• purrTTY.netkan declares the dependency without any version

On top of that, netkan and stamped ckan disagree for purrTTY: purrTTY-1.1.0.ckan in KSA-CKAN-meta carries the exact pin (added by hand in KSAModding/KSA-CKAN-meta@f71c2e7), while the netkan is unpinned, so the next purrTTY release or re-inflation silently drops the pin (the validated inflation output in the artifact of the green e2e run, KSAModding/CKAN-KSA actions run 28718544097, already contains the unpinned form).

None of this has any user-visible effect today, because 0.4.5 is the only StarMap release in the index, so every variant resolves to the same install. That is exactly why now is the cheap moment to decide: the first StarMap release after 0.4.5 will make the three styles behave differently.

Options

1. Exact pin (min_version = max_version, the current majority style): safest against StarMap/game ABI breaks, but every StarMap release requires editing every code-mod netkan, and an out-of-date pin blocks users from installing mods that would work fine (this concern was already raised when purrTTY was added).
2. min_version only (Compendium's current style): low wrangling load, but silently allows a mod to install against an ABI-incompatible newer StarMap.
3. min_version by default, max_version added retroactively once a break is known: middle ground; wranglers act on actual breaks instead of on every StarMap release.
4. Per-version x_netkan_override blocks in each netkan: version-scoped pins without touching old releases.
5. Internal .ckan files in the mod downloads, so authors declare their own StarMap compatibility per release: moves the burden to the authors, who are the ones who actually know the answer, but requires author buy-in and only helps for future releases.

Tasks

• Decide the policy (@averageksp; input from the mod authors and klaaswhite welcome, StarMap's release cadence and ABI-break frequency matter here)
• Apply the decision uniformly to the existing netkans
• Resolve the purrTTY netkan vs stamped-ckan mismatch in whichever direction the policy says
• Document the convention in the KSA wiki drafts (Draft the KSA wiki pages CKAN-KSA#38) and in the netkan example we hand to mod authors

Part of KSP-CKAN/CKAN#4457.