fix: do not mark failed tag migrations as processed

[amandeavor]

Summary

Addresses the soft-fail accounting side of #303 (complementary with #333 for the prose / tool_choice root cause).

When tag generation returns a soft failure ({ success: false }, e.g. empty tool-call arguments over OpenRouter) instead of throwing, handleRunTagMigrationBatch still incremented migrationProgress.processed and eventually reported the migration complete. Untagged memories stayed empty, so the migration modal reappeared on every page load.

Changes

• Track a separate cursor for the batch window (advances even on soft failure)
• Only increment processed after a successful tag write + vector update
• Record soft failures in migrationProgress.errors (same path as thrown errors)
• Reset counters when retrying after a completed pass so a later run can finish previously failed items
• Batch API returns errors count; dialog avoids false 100% success toast
• Soft-fail toast uses i18n (toast-migration-tag-failures)

Relation to #333

#333 forces tool calls / fixes the contradictory migration prompt so prose-without-tool_calls is rarer. This PR makes remaining soft failures visible and retryable. Merge both to close the modal-loop fully. Empty arguments: "{}" is still not “healed”, only surfaced.

Does not solely close #303.

Test plan

• bun test tests/tag-migration-soft-failure.test.ts — soft-fail provider leaves processed === 0, records 2 errors, and never writes tags/vectors
• Both merge orders with fix(ai): force tool calls so tag generation stops returning prose #333 onto main verified clean (319→333 and 333→319)
• Manual: open Web UI with untagged memories, force provider soft-fail, confirm modal does not claim success and remigration can retry

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[karaaslanz]

I traced the changed batch semantics through the current Web UI before treating this as complete. The cursor/processed split fixes the backend bookkeeping, but the user-visible success path is still wrong on an all-soft-failure pass.
TagMigrationDialog.runTagMigration() only reads { processed, hasMore, total } from /api/migration/tags/run-batch. When the batch reaches the end, it unconditionally sets progress to 100, shows toast-migration-success, and closes the dialog. With this PR's own regression scenario (processed === 0, hasMore === false, two errors), the UI will therefore still claim success even though nothing was migrated.
I think this needs one more contract change before it closes #303: expose an error/failure count (or otherwise return a non-success terminal state) from the batch endpoint and make the dialog avoid the success toast / 100% state when failures remain. A focused UI/API regression for the 0 processed + terminal soft failures case would lock the actual symptom the issue reports.

[amandeavor]

Addressed in 9198ce1:

• Batch API contract: handleRunTagMigrationBatch now returns �rrors: migrationProgress.errors.length in its response data.
• Web UI (TagMigrationDialog): Track otalErrors across batches. When soft failures occur, the dialog avoids the unconditional 100% progress and success toast terminal state; instead, it retains the actual progress percentage, surfaces the error count via an error toast and status line, and resets running state so the user is informed rather than claiming a false success.
• Tests: Extended ests/tag-migration-soft-failure.test.ts to verify �atch.data.errors reflects soft failure counts accurately.

[karaaslanz]

Re-checked the updated head after the follow-up. The API now exposes the cumulative soft-failure count and the dialog no longer turns a terminal soft-failure pass into a 100% success state, so the user-visible issue I called out is addressed. The focused regression passes as well. Looks good from this review scope.