RAISING-PLAYER-CAP.md: sharpen the drop-zone wording

The previous correction overstated the case by implying the code reading was
wrong outright. It was not. The engine really does place surplus 'Mechs on
already-occupied spawn points -- two 'Mechs dropped on the same spot -- exactly
as reading the code suggests.

The only wrong part was the predicted consequence. The original draft said those
players "silently fail to spawn". They do spawn; the collision system then pushes
the stacked 'Mechs apart within a second or two, costing some minor contact
damage, and play continues normally.

Reworded Layer 7 and the known-traps entry to separate the two claims: the
spawn-point reuse is real and code-predictable, the failure-to-spawn conclusion
was not.

Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>

RAISING-PLAYER-CAP.md

@@ -173,12 +173,14 @@ scoreboard. Defer.
 
 ### Layer 7 ? Map content (drop zones: a polish item, NOT a blocker)
 
-Most stock maps define ~16 drop zones / start points.
+Most stock maps define ~16 drop zones / start points. When there are more 'Mechs than drop zones,
+the surplus 'Mechs **are placed on already-occupied spawn points** ? two 'Mechs dropped on the same
+spot. That part happens exactly as reading the code suggests.
 
-**This was previously assumed to be the gating task. It is not.** Verified empirically on real
-pods: when there are more 'Mechs than drop zones, the surplus 'Mechs **spawn on top of each
-other**. They clip and collide for a moment, take some minor damage, then separate and play
-normally. It resolves itself within seconds.
+What does *not* follow ? and what an earlier draft of this document got wrong ? is the consequence.
+The surplus 'Mechs do **not** fail to spawn. They spawn stacked, the **collision system separates
+them within a second or two**, they take some minor contact damage in the process, and play
+continues normally. Verified on real pods.
 
 So a drop-zone shortfall is a **quality-of-experience issue, not a functional failure**. It does
 not block raising the cap, and it should not gate the schedule.
@@ -240,7 +242,8 @@ design suggests none exist, but grep for it.
   `nLaunchState = 3` forever because `CTCL_CheckServerReady` never sees
   `nCount == g_nTeslas + 1` and matching lancemates. If you see that, suspect a count mismatch,
   not a crash.
-- **Drop-zone shortfall is benign** ? surplus 'Mechs spawn stacked, bump, take minor damage and
-  separate. Do not mistake this for a bug, and do not let it gate the work.
+- **Drop-zone shortfall is benign** ? 'Mechs really are dropped onto shared spawn points, but the
+  collision system separates them within seconds for minor contact damage. Do not mistake this for
+  a bug, and do not let it gate the work.
 - **Writing 32 into a 5-bit field truncates to 0**, which will look like "max players became
   unlimited/zero" rather than an overflow.