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/DoubleUpEnemyUpgradeOption.cs

@@ -0,0 +1,48 @@
+// Assets/_Project/Scripts/Gameplay/EnemyUpgrades/DoubleUpEnemyUpgradeOption.cs
+using UnityEngine;
+using TD.Gameplay.Waves;
+
+namespace TD.Gameplay.EnemyUpgrades
+{
+    /// <summary>
+    /// Vote-meta card: the next time this wave is cleared, it takes several buffs automatically
+    /// and the players get no say in which.
+    /// </summary>
+    /// <remarks>
+    /// <b>Not an enemy ability.</b> Nothing about the enemies changes when this is voted in — it
+    /// changes how the <i>next vote</i> on this slot resolves. That's why it derives from
+    /// <see cref="EnemyUpgradeOption"/> directly instead of wrapping an
+    /// <c>EnemyAbilityDefinition</c>: the spawn path builds ability sets only from ability cards,
+    /// so this one is recorded on the slot and otherwise invisible to enemies.
+    ///
+    /// <para><b>The trade is agency for information.</b> Voting this in is choosing to make one
+    /// future wave worse in exchange for it not being the worst option — the auto-draw is weighted
+    /// and slot-filtered exactly like a real vote, so it's a gamble on the pool, not a punishment.
+    /// It also disarms itself after firing (<c>ServerConsumeAutoApply</c>), so a slot can only be
+    /// doubled once per card.</para>
+    ///
+    /// <para>Repeats are prevented by the normal offer filter: the slot records this card like any
+    /// other, so it can't be offered to the same slot twice in a phase.</para>
+    /// </remarks>
+    [CreateAssetMenu(fileName = "EnemyUpgrade_DoubleUp",
+                     menuName = "TD/Enemy Upgrades/Double Up Card", order = 22)]
+    public class DoubleUpEnemyUpgradeOption : EnemyUpgradeOption
+    {
+        [Header("Payload")]
+        [Tooltip("How many buffs the wave takes automatically in place of its next vote.")]
+        [Min(2)]
+        public int BuffsToAutoApply = 2;
+
+        public override bool IsValidForSlot(RunState run, int slot)
+        {
+            // Pointless to offer while the slot is already armed — the player would be trading a
+            // vote away for nothing.
+            return run != null && run.GetAutoApplyCount(slot) <= 0;
+        }
+
+        public override void ServerOnApplied(RunState run, int slot)
+        {
+            run?.ServerSetAutoApply(slot, BuffsToAutoApply);
+        }
+    }
+}