#853 8 deterministic test failures: broken assertions + workflow result attributed to switch branch instead of final task

EARS SPEC: - Every test in tests/ shall be capable of passing against correct behaviour; an assertion that can never be True shall be treated as a defect in the test, not a finding about the code. - When a workflow completes, the reported workflow result shall come from the workflow's FINAL task, not from an intermediate branch task. - Stale test expectations shall be corrected DELIBERATELY with the new behaviour justified - never quietly updated to match observed output. CONTEXT: found during the #850 dependency upgrade. Full suite on the post-#850/#851/#852 stack: 8 failed, 551 passed, 10 skipped, 1 xpassed in 1244.27s (20:44) All 8 are DETERMINISTIC (re-ran the fast subset: same 4 failed again, 0 flaky). All 5 affected test files last changed Feb 2026 (81bb4b4 / a0db1d6) - six months and many engine releases ago (#825 #826 #833 #836 #843 #845). No test file was modified by #850/#851/#852. GROUP A - assertions that CAN NEVER PASS (test defects, provably build-independent): 1. tests/unit/test_workflow_run_state_transitions.py::test_update_includes_where_guard assert "AND status NOT IN" in update_sql, where update_sql is a psycopg sql.Composed. PROVEN in-container: "AND status NOT IN" in Composed -> False (what the test does) "AND status NOT IN" in str(Composed) -> True Composed.as_string(None) contains it -> True (the guard IS present) Membership on Composed does element-wise EQUALITY against its parts, never substring. So this assertion is False no matter what SQL is generated - it cannot go green, therefore it can never go red either, and it has been masking whether the guard exists rather than checking it. FIX: assert against .as_string(conn) (or str()), not the Composed object. 2. tests/unit/test_workflow_deadline.py::TestDeadlineFailureHandler::test_fail_single_exceeded_workflow Same family: compares a call() containing a raw SQL string against a Composed/param call. GROUP B - workflow result attributed to the wrong task (ENGINE QUESTION, needs a decision): 3. tests/integration/test_switch_operator.py::test_switch_case_matching 4. tests/integration/test_switch_operator.py::test_switch_default_case tests/workflow_examples/switch_workflow.py:64 success_task echoes "Success: Request completed successfully" tests/workflow_examples/switch_workflow.py:93 final_report echoes "Routing completed" The test asserts the workflow result is final_report's output; it gets success_task's. NOTE the workflow COMPLETED and the step-count assertion PASSED (4 step_succeeded events >= 3), so final_report DID run - only the RESULT ATTRIBUTION is wrong. Either the engine should report the terminal task's result, or the test's expectation is stale and must be corrected deliberately. Same class as #849 (post-release drift in ordering/attribution), not a flake. 5. tests/integration/test_complex_workflow_atomicity.py::test_conditional_branching_true GROUP C - Docker-in-Docker: 6-8. tests/integration/test_docker_tools.py::test_docker_inspect, ::test_docker_compose_simple, ::test_docker_network_isolation e.g. compose down returned status "running", expected "stopped" - teardown/timing. ATTRIBUTION - WHAT IS PROVEN AND WHAT IS NOT: PROVEN: Group A cannot pass on ANY build (assertion is structurally impossible) - unrelated to #850. NOT PROVEN: I could not run a dependency baseline (bulkman 2.0.1 / resilient-circuit 0.4.7) to demonstrate Groups B and C failed BEFORE the upgrade. The runtime image ships no pip and no uv (minimal, compiled-bytecode image), so an in-place downgrade is impossible; a real baseline needs a rebuild with the old pins. Mechanically these paths are not reachable from the change - circuit breakers are DISABLED ([features] circuit_breaker_enabled = false, verified in-container), and bulkman 2.0.1->2.0.3 is pin-widening only - but that is REASONING, not a reproduction. Per the standard set in #849, a baseline rebuild should be run before calling these pre-existing.