Import endpoint: manual conflict-review workflow (POST /resolve)

[DutchJaFO]

Context

Deferred out of #45 (import endpoint) — see the scope-change comment on #45 and docs/milestones/data-import-sources/45-import-endpoint-plan.md's Scope changes section.

#45 ships automatic conflict detection and resolution (all 5 policies from #64: skip, newest-wins, merge-ours, merge-theirs, review), logging every conflict to System_ImportConflicts. review-policy conflicts are left Status = "pending" in that table but nothing currently lets a user resolve them — they just stay pending forever.

This issue is the manual-review half: letting a user look at pending conflicts and decide, per field, which side wins.

Blocked on

#56 (audit log) — not started. The original design (from #45's stale issue text) required every resolution decision to be recorded with ActorType='user', Action='updated', old/new values — that needs #56's IAuditLogger/AuditLog table to exist first.

What this issue should deliver

1. GET /api/v1/quotes/import/conflicts?status=pending (or similar) — list pending System_ImportConflicts rows, likely paginated (mirror System_AuditEntries' existing paging pattern).
2. POST /api/v1/quotes/import/conflicts/{id}/resolve (or similar — exact route TBD at planning time) — accepts a per-field resolution (keep existing / replace with incoming), updates the quote's stored fields accordingly, and marks the System_ImportConflicts row Status = "resolved", ResolvedAt set.
3. Each resolution recorded in the audit log (Audit log: provenance and change history across all entity types #56) with the acting user, old value, new value per field.
4. Decide at planning time: does this reuse FieldMergeResolver's existing merge machinery, or is a per-field keep/replace decision simple enough to not need it?

Notes

• ExistingValue/IncomingValue/MergedFields on System_ImportConflicts are already opaque JSON blobs holding the exact field-level data a review UI would need to render a side-by-side comparison — no schema change anticipated for this table itself.
• The eventual Blazor import UI (milestone Language selector 404 under HA ingress (missing PathBase in form action) #11) is the likely consumer of this API, but this issue is API-only, matching how Import endpoint: POST /api/v1/quotes/import #45 itself was API-only.

[DutchJaFO]

No plan doc will be created yet — this issue is blocked on #56 (audit log, still in Planning) and is far enough down the dependency chain that planning it now would be premature. Logged per this repo's checklist.md ("For any new issue without a plan doc: confirm the no-plan-doc decision is logged in the GitHub issue and in overview.md"); overview.md's Issue List carries the same note. A plan doc will be created once #56 starts.

[DutchJaFO]

Scope reconciliation

The original issue described a single-shot API: POST .../resolve accepts a per-field keep/replace decision and immediately applies it. During planning this was redirected to a git-merge-style staged workflow instead, after several rounds of design review. Summary of what changed and why (full detail in 149-manual-conflict-review-plan.md):

1. Side labeling — responses now clearly show existing vs incoming, including a human-readable label for each side's originating import batch, and a sameFile flag when both sides of a conflict came from the same imported file (a single file can itself contain two entries sharing one quote ID).
2. Per-field custom override — a caller can supply their own value for a field, not just keep-existing/take-incoming, validated the same as any normal quote field.
3. The decision itself is stored (not just a status flip), so it can be undone before commit.
4. Nothing executes until every conflict in an import batch has a decision — a new explicit POST /conflicts/apply call, mirroring git: resolving individual conflicts doesn't auto-commit.
5. Maximized reuse in Quotinator.Data — the entire staging/undo/readiness-checking workflow (IConflictResolutionCoordinator) is domain-agnostic and lives in Quotinator.Data; only the one genuinely domain-specific step (writing a resolved field map to Quotinator's own tables) lives in Quotinator.Engine.
6. Route placement — endpoints landed at a new top-level /api/v1/import group (not nested under /api/v1/quotes or /api/v1/admin), aligning with the direction in Review endpoint grouping: split Admin / Quote / Import into distinct tags and route groups #152. Note: Review endpoint grouping: split Admin / Quote / Import into distinct tags and route groups #152's own remaining scope (moving the existing /api/v1/quotes/import(/preview) endpoints into this same group) was not folded into this issue — it stays open as its own separate piece of work.
7. Deferred to a separate future issue: undo after a batch has already been applied, and a declarative "conflict resolution file" for recurring conflicts from third-party sources not under our control.

Final endpoints:

• GET /api/v1/import/conflicts — paginated list, filterable by status/batchId
• POST /api/v1/import/conflicts/{id}/decide — stage a decision (nothing written yet)
• POST /api/v1/import/conflicts/{id}/undo — revert a staged decision
• POST /api/v1/import/conflicts/apply?batchId= — apply an entire batch atomically, once every conflict in it has a decision

Implementation, tests (898/898 passing), and T2 (Docker) are complete. T1 (Visual Studio) verification pending.

[DutchJaFO]

Released in v1.8.0.

#	Status	Requirement	Method	Verification
1-2	✅	ResolveWithDecisions explicit decisions win; auto-resolve/throw for undecided fields	Unit test	FieldMergeResolverTests.ResolveWithDecisions_* (6 cases)
3	✅	Writer/reader status transitions round-trip correctly	Unit test	SystemImportConflictWriterReaderTests
4-5	✅	Coordinator: decide/undo/batch-apply state machine correct, atomic, rolls back on failure	Unit test	ConflictResolutionCoordinatorTests (against a fake callback — no real schema needed)
6	✅	Baseline/incremental schema parity including ExistingBatchId	Unit test	DataOwnedBaseline_And_IncrementalReplay_ProduceIdenticalSystemImportConflictsSchema
7-10	✅	Service layer: ambiguous-field reporting, decide/apply resolves FK fields correctly, undo works	Unit test	SqliteConflictResolutionServiceTests
11	✅	All four endpoints: correct auth, status codes	Unit test	ImportConflictEndpointsTests (13 tests)
12	✅	Build/tests clean	Live	898/898 passed
13-14	✅	T1/T2 — full decide→undo→decide→apply cycle against a real conflict	Live	Confirmed

Note: /import/conflicts/* and this issue's own coordinator/service were later retired in favor of /import/actions/* (#154 Phase B) — see #154's closing comment. The design and correctness work here carried forward into that replacement.