Batch team messages across Tank Royale

[flemming-n-larsen]

Objective

Add ordered batches of logical team-message payloads to the existing Tank Royale team-message packet and event, using Java as the semantic reference for the Java, .NET, Python, and TypeScript Bot APIs. This is a plan-less change. If merged, it would bind the batching and message-size/count behavior recorded in CAP-006.

Candidate contract

• At most 64 team-message packets and 128 logical payloads per bot per turn.
• At most 49,152 UTF-8 bytes per encoded packet and 262,144 UTF-8 bytes for the compact teamMessages array per turn.
• Batch version 1 is required from every recipient; messages preserve order and arrive on the next turn.
• Invalid intents are rejected atomically; incoming WebSocket text is bounded to 1 MiB before parsing.
• No compression is included. Tank Royale 1.4.0 and its changelog are updated on this branch; no release is published.

These are draft trial limits. The stress acceptance gate has not passed, so they are not accepted or published policy.

Verification evidence

• PRO-006: scenario evidence verifies ordered batch delivery and next-turn behavior; shared cross-platform tests cover broadcast, directed delivery, ordering, Unicode, and byte boundaries.
• PRO-007: server and API tests cover atomic rejection, including 262,145 bytes; 262,144 bytes is accepted.
• PRO-008: raw-client test verifies oversized WebSocket text is rejected before JSON parsing.
• PRO-009: server test covers a directed message to a teammate who disconnected after game start.
• Prior matched API suites passed: Java, Python, server, .NET (299 tests), and TypeScript (322 tests). clue validate passes.
• The instrumented 128-entry stress sequence completed 8 fresh paired executions: 7 stress passes and 1 failure. In the failed run, one bot skipped a turn with 0 µs minimum remaining time; each of the other four teammates reported one missing 128-item batch and an ordering gap. The 128-entry gate remains unresolved.
• A separate 64-entry batch trial passed 10/10 fresh paired executions on the user's fast local PC. Each bot received all 15,360 expected items in order, with zero skips. Throughput was 99.1–118.6 turns/s; minimum remaining time was 8.581–15.803 ms and average remaining time was 26.958–27.589 ms. The matched control's minimum was 21.234–25.461 ms. This result does not establish reliability on average or lower-spec hardware; 64 is a test fixture only and has not changed the candidate API limit.
• The encoded 64-entry outbound arrays totaled 1,378,320 bytes; estimated teammate payload fan-out was 5,513,280 bytes, excluding WebSocket framing and transport overhead.
• ./gradlew clean build currently fails at :runner:test because TestPurposeArchitectureTest flags two existing tests in booter/.../ProcessLauncherTest.kt and one Kotest spec in server/.../TeamMessageRawClientTest.kt as missing recognized purpose tags. It did not report the new 64-entry tests. .NET (299) and TypeScript (322) tests passed in that build.
• CombatTeam completed five rounds against the matched 1.4.0 API and runner with zero reported errors; scores were 10,645 classic / 13,367 Tank Royale (+25.6%). The score difference remains unresolved and does not establish message loss.
• Bridge team-message conformance passed against the matched local build. Book pages and the Book build were updated and verified.

State

Draft. The 128-entry 30 TPS zero-loss, zero-skip gate failed, and the 64-entry result is limited to a fast local host with single-digit-millisecond minimum margin. Keep the candidate unpublished pending a run on representative slower hardware or an agreed calibrated CPU limit. No release or integration-branch push is requested.