Clarify task source categories and reconcile corrected creates

[witbrock]

Merge decision: ready — a corrected source-category validation error can now yield a completed task-creation answer while retaining both failed attempts and the verified task receipt.

User outcome

Creating a task from a Gmail message previously rejected an external message ID supplied as task_source_id or source_id. A later successful correction still produced partial-completion finality. This change clarifies that both fields name a registered source category and that external provenance belongs in notes or reference_code.

Native task: #V#task_agent_2f3b1c23fb52c2ec365e826603aa2a8c.

Material changes

• Explain source categories, aliases, the native default and external references in the exposed tool contract and validation feedback.
• Extend existing task-creation recovery to normalise the source alias and reconcile a no-change unknown-source rejection with a later verified creation whose remaining request arguments match.
• Preserve failed receipts and link recovery to the successful effect; retain unresolved differences in scope, assignment, preferences, priority, dates and provenance.

Evidence

• Sanitised regression failed before the fix and passed afterwards.
• VON_USE_MOCK_DB=1 pdm run pytest tests/backend/test_coding_task_creation_recovery.py tests/backend/test_adaptive_turn_service.py tests/backend/test_task_ontology_service.py tests/backend/test_internal_mcp_task_parity_tools.py -q: 370 passed.
• The faithful replay exercises the real gateway, task service and adaptive final-response path with an isolated in-memory database and scripted model responses: two rejected source variants, one canonical task, retained provenance, preserved failure observations, recovered finality. Omitting the requested high priority still gives partial completion.
• Existing task-type recovery tests and source-recovery negative cases pass. git diff --check and pdm lock --check pass. Formatter differences in the ontology file are confined to unchanged lines.

Ship boundary

• Minimum ship criteria: clarified exposed contract and the bounded regression outcomes above.
• Stop-ship conditions: falsely forgiving a distinct or materially incomplete request, losing failed receipts or provenance, or duplicating creation on the tested correction path.
• Limitations: isolated acceptance; no live model or production task mutation. The existing incident task was left untouched.
• Non-goals: Gmail OAuth, date/time semantics, UI changes, migration, general effect-framework redesign, or deployment. No deployment requested.