[Follow-up] Batch planner lane loses column-ambiguity diagnosis (TryParseOperationsAsync returns null)

[Chris0Jeky]

Context

PR #3444 (fixing #3427) routes column-name resolution through
ColumnNameResolver, which distinguishes Found / NotFound / Ambiguous.
The single-instruction planner lane surfaces the precise ambiguity
message, but TryParseOperationsAsync (used by the batch lane) can only
return List<CreateProposalOperationDto>?: ambiguity maps to null,
and the caller funnels that into parseErrors → generic
BuildParseHintMessage ("Could not parse instruction…"). In a mixed
batch the ambiguous instruction is silently skipped with only an
"(N instruction(s) could not be parsed)" suffix. Fail-closed (no
wrong-column write), but the specific diagnosis is lost.

Evidence

• backend/src/Taskdeck.Application/Services/AutomationPlannerService.cs
TryParseOperationsAsync: if (resolution.Outcome == ColumnResolutionOutcome.Ambiguous) return null; (3 sites).
• Caller funnels null into parseErrors
  (ParseBatchInstructionCoreAsync), then BuildParseHintMessage.
• Pre-existing shape: NotFound was already lossy here, so this extends
  an existing wart rather than introducing one.

Acceptance criteria

• A batch instruction that fails only on ambiguous column names
  surfaces the ambiguity (column name + rename remedy) instead of a
  generic parse failure, e.g. via a discriminated parse result from
  TryParseOperationsAsync (internal method; callers are the single
  and batch cores).
• Mixed batches still apply the unambiguous instructions and report
  the ambiguous one(s) specifically.
• Regression tests: batch ambiguity surfaces the message;
  single-lane behaviour unchanged.

Follow-up to review finding on #3444. Fail-closed safety already
holds; this is diagnostics quality only.