First pass at full refactor to 2.0 design

Restructures the game around the cyclical run loop from Game Design Doc V2:
5 waves = a cycle, 3 cycles = a phase, each phase ends in a boss.

- New TD.Gameplay.Waves: WaveGroup / PhaseDefinition / RunDefinition author the
  run as draggable weighted pools; RunState owns phase/cycle position, the drawn
  wave slots, and the per-slot enemy buff sets. WaveManager's flat wave array is
  gone -- it now only runs the encounter RunState points at.
- New TD.Gameplay.EnemyUpgrades: the post-wave enemy-buff vote, with public
  live-replicated ballots so the HUD can show who voted for what.
- Inter-wave flow is now strictly sequential: draft -> vote -> build, each stage
  ending early once every player has acted.
- Enemy abilities inverted from per-instance random rolls to deterministic,
  stacking per-wave-slot sets. Six cards ship: Split (reworked), Flight, Blink,
  No Bounty, Gold Theft, Double Up.
- Tower upgrades are a two-step tree: a draft pick unlocks a node, gold converts
  an already-placed tower in place.
- Boss encounters flag their enemies and drive a boss HP bar.
- Player cap reduced to 3 via MatchRules.MaxPlayers.
- GoldConfig is now keyed by global encounter number rather than wave index.

Compiles clean; NOT yet verified in-engine. Editor wiring still required --
see Docs/2.0_Setup_Checklist.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assets/_Project/Scripts/Core/MatchRules.cs

@@ -0,0 +1,26 @@
+// Assets/_Project/Scripts/Core/MatchRules.cs
+namespace TD.Core
+{
+    /// <summary>
+    /// Match-wide constants that several unrelated systems have to agree on.
+    /// </summary>
+    public static class MatchRules
+    {
+        /// <summary>
+        /// Maximum players in one lobby.
+        /// </summary>
+        /// <remarks>
+        /// <b>Reduced from 9 to 3 for the 2.0 design</b> as a deliberate scope cut: three players
+        /// is enough for the shared-lives and shared-vote mechanics to matter, and it shrinks map
+        /// authoring, balance surface, and network load all at once.
+        ///
+        /// <para><b>Why <see cref="PlayerSlot"/> still runs to 9.</b> Shrinking the enum would
+        /// invalidate the owner grids baked into existing <c>LevelData</c> assets and force a
+        /// re-bake of every map, for no runtime benefit — the extra values are simply never
+        /// allocated. Slot allocation caps here instead, which is the only place that decides who
+        /// gets a slot at all. Per-slot arrays stay sized to the enum, so they hold a few unused
+        /// entries; that is intentional and costs nothing.</para>
+        /// </remarks>
+        public const int MaxPlayers = 3;
+    }
+}