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/EnemyUpgrades/EnemyUpgradeOption.cs

@@ -0,0 +1,66 @@
+// Assets/_Project/Scripts/Gameplay/EnemyUpgrades/EnemyUpgradeOption.cs
+using UnityEngine;
+using TD.Gameplay.Waves;
+
+namespace TD.Gameplay.EnemyUpgrades
+{
+    /// <summary>
+    /// Base class for one card in the post-wave enemy-buff vote. Players collectively choose one
+    /// of these to permanently attach to the wave they just cleared; it takes effect the next time
+    /// that wave comes round in the cycle.
+    /// </summary>
+    /// <remarks>
+    /// <para><b>Mirrors <c>DraftOption</c> deliberately.</b> Same shape — abstract SO, one asset
+    /// per card, concrete subclasses carry the payload — so the two authoring surfaces read the
+    /// same way. The difference is who it targets: a draft option applies to a player, an enemy
+    /// upgrade applies to a <i>wave slot</i>.</para>
+    ///
+    /// <para><b>Identity.</b> Options live in <see cref="EnemyUpgradePool"/> and cross the network
+    /// as their pool index, the same stable-within-a-match id pattern used by the tower catalog
+    /// and draft pool.</para>
+    ///
+    /// <para><b>Recording is not this type's job.</b> <c>WaveVote</c> records the winning option id
+    /// onto the slot via <c>RunState.ServerAddUpgrade</c>; <see cref="ServerOnApplied"/> is only
+    /// for cards that need a side effect <i>beyond</i> being recorded (the vote-meta cards).
+    /// Ability cards need nothing here — the spawn path reads the slot's recorded set.</para>
+    /// </remarks>
+    public abstract class EnemyUpgradeOption : ScriptableObject
+    {
+        [Header("Presentation")]
+        [Tooltip("Name shown on the vote card.")]
+        public string DisplayName;
+
+        [Tooltip("Short description shown on the vote card. Say what it does to the enemies, in " +
+                 "the players' terms — this is the only thing they get to judge the vote on.")]
+        [TextArea(2, 4)]
+        public string Description;
+
+        [Tooltip("OPTIONAL override for the vote card icon. Leave empty to inherit the icon of " +
+                 "whatever this option grants.")]
+        public Sprite Icon;
+
+        /// <summary>
+        /// Icon actually shown on the vote card. Subclasses override to fall back to the icon of
+        /// the thing they grant; the base has nothing to inherit from, so it returns
+        /// <see cref="Icon"/> (which may be null).
+        /// </summary>
+        public virtual Sprite ResolveIcon() => Icon;
+
+        /// <summary>
+        /// Server-only: may this option be OFFERED for <paramref name="slot"/> right now? Default
+        /// true; override for cards with prerequisites or ones that would be a no-op.
+        /// </summary>
+        /// <remarks>
+        /// Callers already skip options the slot has taken before, so implementations don't need
+        /// to re-check that.
+        /// </remarks>
+        public virtual bool IsValidForSlot(RunState run, int slot) => true;
+
+        /// <summary>
+        /// Server-only: side effect to run after this option has been recorded onto
+        /// <paramref name="slot"/>. Default no-op — most cards do their work at enemy-spawn time
+        /// by virtue of being on the slot, not at vote-resolution time.
+        /// </summary>
+        public virtual void ServerOnApplied(RunState run, int slot) { }
+    }
+}