fix: resolve state-backed strategy work items

[ApexWorm]

Problem

desloppify plan resolve strategy::<id> classifies the strategy ID as a plan-only synthetic item. The workflow resolver removes it from the plan and prints Resolved, but does not resolve the backing state work item, so next can enqueue it again.

Fix

Route strategy:: items through the normal state-backed resolution path. Workflow, triage, and subjective synthetic items retain their existing plan-only handling.

Verification

• python3 -m pytest -q -p no:cacheprovider desloppify/tests/commands/plan/test_plan_overrides_direct.py desloppify/tests/commands/plan/test_workflow_gates.py desloppify/tests/commands/plan/test_strategist.py desloppify/tests/commands/test_queue_order_guard.py desloppify/tests/commands/resolve/test_cmd_resolve.py
• ruff check desloppify/app/commands/plan/override/resolve_helpers.py desloppify/tests/commands/plan/test_plan_overrides_direct.py
• git diff --check

[daBOB]

Independently reproduced and verified this fix against persisted CLI fixtures (related reports: #747 and #773).

The fixtures create real strategy work items with the strategist's production helper, save state/plan to a temporary project, invoke python -m desloppify --lang python plan resolve ..., and reload both files after next.

• Exact strategy::ownership-audit, strategy::*, and mixed workflow + strategy commands persist fixed and do not reinsert the strategy item after next with this patch. They leave the backing item open before it.
• *::ownership-audit already works before the patch and produces equivalent persisted status, note and resolution attestation afterward. It is a supported workaround while this awaits merge.
• Too-short notes, missing attestation, and resolving a later exact strategy ID are correctly blocked with this patch; previously the synthetic path printed success and bypassed those checks.
• A missing strategy:: ID now reports no matching open issue instead of claiming it was resolved.
• The cluster-name fixture encounters the separate queue-order defect discussed on fix: preserve queue and triage scopes #686 both before and after this PR: a derived workflow::run-scan blocks the persisted front cluster. Combining this PR with the independently reviewed queue-prefix fix makes that case pass too. This is not a regression introduced here.

Results: nine CLI cases before = 8 failed / 1 passed; this PR alone = 8 passed / 1 unchanged cluster-guard failure; combined queue fix = 9 passed. Existing nearby resolve/workflow/strategist/queue tests: 84 passed. Full combined upstream suite: 6829 passed, 18 skipped, 2 failed; both failures are the duplicated historical test_do_run_batches_dry_run_generates_packet_and_prompts cases, independently reproduced on pristine 3a7735d. Ruff and whitespace checks pass.

No application sources, original project scanner state, or installed CLI were changed during verification. The global synthetic-prefix semantics remain untouched; the correction is local to resolution routing.