[Agent] Log shipper max batch (500) exceeds the API's 200-entries-per-request cap — full batches rejected wholesale

[ToddHebebrand]

Description

The agent log shipper accumulates up to 500 entries per flush, but the API logs endpoint rejects any request with more than 200 entries. A full batch therefore 400s as a unit, and since 4xx responses are never retried, all 500 entries are dropped — precisely under bursty logging, when logs matter most.

Root Cause

• agent/internal/logging/shipper.go:36 — defaultMaxBatchSize = 500 (buffer also 500).
• apps/api/src/routes/agents/logs.ts:37 — logs: z.array(agentLogEntrySchema).max(200).
• agent/internal/logging/shipper.go:322-333 — any 4xx drops the whole batch, no retry (correct policy for genuinely bad entries, wrong outcome for a size-shape mismatch).

Same burn-the-batch failure class as #2386 (oversized fields), which PR #2392 fixed with a pre-ship fields size cap — the batch-count dimension was flagged there and deliberately left for this issue.

Proposed Fix

Chunk flushes agent-side to ≤200 entries per request (the server cap must stay — self-hosted API versions vary). Keep buffer/batch accumulation at 500 if useful; just split the HTTP sends. Add a test that a 500-entry flush produces 3 requests and a mid-chunk 4xx only drops that chunk.

Affected Files

• agent/internal/logging/shipper.go (primary)

Found during #2386 (PR #2392 review).

[ToddHebebrand]

Fix open: PR #2402 — chunks each flush into <=200-entry requests (maxEntriesPerShipRequest, pinned to the API cap in apps/api/src/routes/agents/logs.ts by a contract test). A mid-batch 4xx now drops only that chunk, 429/5xx retries apply per chunk, and terminal failures (dead server, 401) abort the remaining chunks with counted drops. Server cap untouched. Review-clean; awaiting merge.