Preflight all externalized payload sizes before starting uploads

Read internal/largepayload/bounded.go and internal/largepayload/codec.go, then inspect the existing tests under internal/largepayload. Add a message-wide size-validation pass before storage operations begin, preserving the stated concurrency and cancellation behavior. Verify orchestration and entity batch cases, including valid fields before an oversized field, UTF-8 boundaries, all-valid messages, and cancellation; done means deterministic size failures make zero storage calls and leave original fields unchanged.

Outgoing payload transformations collect a plan, but the plan does not validate all payload sizes before dispatching storage operations. MaxPayloadBytes is checked inside each operation. A deterministically oversized later field can therefore be rejected only after valid earlier fields have already created stored payloads.

Current source evidence

Inspected current main at c713409eb9a4295884169c144df9221f9a42aef6.

• TransformOrchestratorResponse adds custom status and action fields to a transformation plan.
• transformPlan.add and run snapshot a field and queue a closure that calls the transform inside runBounded; they do not perform a message-wide size-validation pass.
• Externalize checks the current raw payload maximum and then calls StoreToken or Store.
• The worker abandons the orchestration work item if transformation fails. Earlier successful storage operations are not rolled back or registered with the backend by that abandonment.

Requested regression

Add a source-level regression to the existing internal/largepayload tests using a counting in-memory store/resolver, actual protobuf types and TransformOrchestratorResponse:

1. Configure ThresholdBytes: 8 and MaxPayloadBytes: 32.
2. Create a response with a valid 16-byte custom status, eight valid 20-byte ScheduleTask.Input fields, and a final 33-byte ScheduleTask.Input.
3. Record store calls and original response field values before calling the real transform.
4. Expect errors.Is(err, api.ErrLargePayloadTooLarge), zero Store/StoreToken calls, and unchanged original fields.

The response intentionally contains more fields than the eight-operation concurrency cap. With the current scheduler, a valid operation must complete and release a slot before the late oversized operation is reached, exposing the avoidable earlier storage write without relying on the relative start order of two goroutines. Repeat for TransformEntityBatchResult.

Evidence boundary: the current code establishes the missing message-wide preflight. The proposed Go regression has not been executed for this filing; the equivalent JavaScript case was reproduced and fixed.

Acceptance Criteria

• Validate all relevant raw payload sizes in an outgoing transformation plan before starting any storage operation.
• A deterministic maximum-size violation produces zero storage calls and leaves original payload fields unchanged.
• Preserve current Go size-validation scope, provider-specific inclusive threshold policy, defaults and option normalization.
• Preserve native-token and wrapped-reference idempotency, field deduplication, and snapshot-based transformation.
• Once validation succeeds, retain bounded concurrency, cooperative cancellation, draining of dispatched operations and message-order I/O failure selection.
• Preserve no-op/missing-configuration behavior and do not change hydration semantics as an unrelated part of this repair.
• Add valid-first/oversized-later orchestration/entity cases, UTF-8 boundaries, all-valid messages and cancellation coverage.
• Document that deterministic invalid size is found before hypothetical earlier storage I/O failures.

Non-goals

This is not a cross-store transaction or a generic orphan collector. Real I/O/cancellation/uncertain-submission failures can still leave stored data. Do not unconditionally delete earlier uploads after an uncertain completion outcome: the backend may already have accepted a reference.

Carryover history is already explicitly traversed, and TestTransformContinueAsNewCarryoverEvents covers a large event. The JavaScript carryover field omission does not need a separate Go issue.

Related

• JavaScript zero-upload preflight fix.
• .NET tracking issue 820.
• Go issue 169 tracks late worker failure completion and entity unlock cleanup. It does not cover message-wide validation before storage writes.