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/Gameplay/WaveDefinition.cs

@@ -41,5 +41,64 @@ namespace TD.Gameplay
 
         [Tooltip("Enemy groups that make up this wave. Processed in order.")]
         public WaveEntry[] Entries;
+
+        /// <summary>
+        /// The enemy type this wave is "about" — the first assigned entry's type. Null if the
+        /// wave has no usable entries.
+        /// </summary>
+        /// <remarks>
+        /// The 2.0 design gives each wave a single enemy type, and enemy upgrades are keyed to a
+        /// wave slot, so this is the identity the phase draw uses to keep slots distinct and the
+        /// HUD uses to label an upcoming wave. <see cref="Entries"/> still supports multiple
+        /// groups (useful for staggering counts of the same type), but mixing <i>types</i> within
+        /// one wave makes this ambiguous — see <see cref="HasSingleEnemyType"/>.
+        /// </remarks>
+        public EnemyDefinition PrimaryEnemyType
+        {
+            get
+            {
+                if (Entries == null) return null;
+                foreach (var e in Entries)
+                {
+                    if (e.EnemyType != null && e.Count > 0) return e.EnemyType;
+                }
+                return null;
+            }
+        }
+
+        /// <summary>
+        /// True if every usable entry in this wave spawns the same enemy type. False means
+        /// <see cref="PrimaryEnemyType"/> is only telling part of the story — the run validator
+        /// warns on these rather than rejecting them, since a mixed wave still plays fine, it
+        /// just labels and upgrades oddly.
+        /// </summary>
+        public bool HasSingleEnemyType
+        {
+            get
+            {
+                var first = PrimaryEnemyType;
+                if (first == null) return false;
+                foreach (var e in Entries)
+                {
+                    if (e.EnemyType != null && e.Count > 0 && e.EnemyType != first) return false;
+                }
+                return true;
+            }
+        }
+
+        /// <summary>Total enemies spawned per zone by this wave, across all entries.</summary>
+        public int TotalEnemyCount
+        {
+            get
+            {
+                if (Entries == null) return 0;
+                int total = 0;
+                foreach (var e in Entries)
+                {
+                    if (e.EnemyType != null && e.Count > 0) total += e.Count;
+                }
+                return total;
+            }
+        }
     }
 }