Preserve Odoo maintenance failure evidence before sender checks

[shiny-code-app]

A Dokploy maintenance schedule can report done even when the Odoo module update failed. If a company sender was requested, the sender check previously raised first and discarded the schedule evidence before the caller could diagnose the module failure.

Module proof now precedes that sender check. A typed failure carries bounded schedule/deployment IDs and allowlisted boolean/numeric readback markers into stable post-deploy and preview failure results. The existing deployment evidence mapping persists those details. Missing or false proof still fails; raw logs, SQL rows, credentials, and sender values are excluded.

Validation: 204 focused tests pass, including a provider-done XML-load failure with missing/false module completion crossed with missing/false/true sender proof, persisted deployment evidence, redaction/bounds, and failed preview maintenance skipping smoke. All 3,610 local unittest targets across 12 shards, Ruff, formatting, and mypy (1,053 files) pass. JetBrains explicit inspection of all seven PR files returned RED with 84 findings: 83 on unchanged lines and one explicit default argument in the new deployment fixture, retained to identify the tested workflow intent. The previous clean-worktree changed-files report did not prove full PR coverage. No suppression or profile change.

Independent review: Anthropic claude-opus-5-5 found no actionable problems in precedence, evidence custody, bounds, failure state, or compatibility. It noted the intentionally stricter sender-requesting legacy CLI path; the typed service paths retain the diagnostic evidence. No schema or authorization change is included. Background review is not yet observable at PR creation.

Owner test notes: Nothing for the owner to test. This repairs Launchplane's failure diagnosis and does not change tenant content or data. No CM production operation was retried.

Refs #2513. This remains separate from #2516 for the approved #2494 qualification pair. The approved protected-batch decision is now implemented and the pair is delivered.

Delivery: final source checks and all 65 combined candidate checks passed. LP landed #2516 and #2517 through protected batch #2526 in one controller call at 42b8e589b967623df736b38657313c58174e3402, trace launchplane_req_5904e4ed57d6494d8888b5abb4d9d25a. Post-merge CI, Security, CodeQL, and Deploy Launchplane succeeded. The live image digest matches that exact landing. #2494 records the full qualification, separate admissions/outcomes, and managed feedback. Source refs were restored unchanged after GitHub's existing automatic post-merge deletion; no extra merge occurred. Local task evidence and IDE state are preserved, and the task worktree/local branch are removed.

After the final base refresh, 201 tests across the three directly affected modules passed again; all seven reviewed PR files were unchanged. Runtime installation is proven by the image readback; failure behavior uses the controlled replay and persisted-record regression. No CM operation was retriggered.

[cbusillo]

Launchplane completed the merge-train step for this pull request.

• Repository: cbusillo/launchplane
• Base branch: main
• Pull request: Preserve Odoo maintenance failure evidence before sender checks #2517
• Controller action: land_batch
• Controller record: merge-train-batch-landing-plan-20260927T015807Z-afeca7c516d5ecdc

Launchplane landed this pull request through protected batch PR #2526.

Launchplane manages this comment and will update it as the train moves.