Validate review reconnaissance envelopes before accepting child launches

[tkstang]

Problem

A final review launched two bounded reconnaissance children at the intended task classes. Both launches were accepted, then rejected incomplete envelopes before repository access. Because the children had already been accepted, replacement was unavailable and the primary reviewer had to repeat both evidence lanes inline.

The observable workflow failure is clear, but the exact missing fields were not retained, so the underlying envelope-construction cause remains unknown.

Proposed direction

• Validate a child request against the selected role envelope before marking the launch accepted.
• Return concrete missing-field diagnostics when validation fails.
• Preserve the ability to correct or replace a request that never reached repository access.
• Add regression coverage for both mechanical and intelligent reconnaissance lanes used by project review.

Acceptance criteria

• An incomplete child envelope fails before accepted-launch state is recorded.
• The failure identifies the missing or invalid fields.
• A corrected or replacement launch remains possible.
• Review workflows retain a durable terminal result for every accepted child.

[tkstang]

Triaged in #330 (record).

Tracked as BL-260927-validate-recon-worker (Validate recon-worker assignment envelopes deterministically before launch). Verified narrower than reported: #285 later added a prose pre-launch envelope check to oat-reviewer, but nothing validates an envelope deterministically or reports missing fields before launch. Replacing an accepted child is intentionally not allowed; continuing the accepted handle with a corrected envelope is. The durable terminal result per accepted child stays with BL-260906-harden-dispatch-launch (Harden dispatch launch baselines and terminal reconciliation) (#266).