batch_priority's documented coverage-target semantic is not implemented

[DariuszNewecki]

What

POST /v1/coverage/generate:batch's priority field is documented (coverage_routes.py, ADR-057 D1) as: priority ∈ {'high', 'all'} — "'high' raises the target [coverage percentage]". This has never actually been implemented, in either the current pipeline or its predecessor.

Verified

• Current: will/self_healing/symbol_coverage_remediation.py::remediate_batch_by_symbol() has no target_coverage/priority-sensitive parameter at all — candidate selection uses a single fixed threshold (_CFG.batch_remediation_threshold_pct) regardless of batch_priority.
• Predecessor (retired in Retire EnhancedTestGenerator (ADR-135 D7 follow-on, never filed) #814): coverage_remediation_service.py::remediate_coverage_enhanced() computed a target_coverage value from batch_priority but never passed it into BatchRemediationService.process_batch() — it was only used in a log line.

So this is pre-existing drift between the documented API contract and the implementation, not something #814 introduced or regressed. Surfaced during #814's implementation and follow-up review (2026-07-18); flagged rather than silently fixed since it needs its own scoped design (what should "high" actually change — a lower/more aggressive coverage threshold? a different candidate count? something else?) and its own tests.

Where

• src/api/v1/coverage_routes.py — documents the contract
• src/will/governance/coverage_runner.py::run_and_persist_coverage_batch — accepts and persists batch_priority on the run row but doesn't act on it
• src/will/self_healing/symbol_coverage_remediation.py::remediate_batch_by_symbol — candidate selection entry point that would need to consume it