Follow-up to the seed tombstones merged in #3573, which introduced this gap.

Onboarding binds each area to a well-known seeded profile id unconditionally.
Once deletions are remembered, a user who had deleted that bundled profile and
later re-ran onboarding got a category pointing at a row seeding now refuses to
recreate: _resolveModel returns noModel and the first task degrades to
title-only. Onboarding is re-runnable from the maintenance page and the
onboarding settings panel, so this is reachable rather than theoretical.

The key step now clears that provider's tombstone before running the FTUE
setup, so the seeding it triggers can recreate the profile. Deliberately
setting the provider up again is the 'bring it back' signal the store's forget
was built for; every other path still honors the deletion.

Exposes the store as seedTombstoneStoreProvider rather than reaching into
getIt from a widget, which also lets tests substitute one.

Also fixes a defect in the tombstone serialization from that same PR: the
mutation queue was a single static, so it was shared across every database in
the isolate. In tests one stalled mutation against a discarded database wedged
every later write, and the onboarding flow hung mid-connect. The queue is now
keyed by settings database, which is both what the serialization actually needs
and test-safe.

Supersedes the SeedTombstoneStore from #3573. Deleting an AI config now stamps
deletedAt on the row and re-saves it, so the row itself is the tombstone.

The ledger was the wrong shape. It lived in settings.sqlite while the config
lives in ai_config.sqlite, so no transaction could span a deletion and a
seeding check — the race CodeRabbit raised, which I could only mitigate with a
post-pass reconciliation. It was local state, so a device that never observed
the delete could re-seed and sync the row back. And two stores writing the same
row could lose an identity, which needed a serialization queue that itself
shipped with a cross-database bug.

The field costs neither of the things I assumed ruled it out. ai_configs stores
the whole config in a serialized TEXT column, so a new freezed field lands in
that JSON and schemaVersion stays 1. SyncMessage.aiConfig already carries the
whole config, so the deletion replicates on the existing path. It also matches
how the journal domain deletes synced entities (CategoryRepository).

Reads split by intent: getConfigById/getConfigsByType hide deleted rows by
default, the seeding passes ask for them so a deleted row reads as present and
blocks re-creation, and watchConfigsByType always filters. Two paths keep
hard-deleting through hardDeleteConfig — removeOrphanedDefaultSeeds and the
provider cascade — because both want their rows back later.

Deletes SeedTombstoneStore, its test, seedTombstoneStoreProvider, the settings
key, recordTombstone, the mutation queue, and the mid-pass reconciliation in
both seeding passes.

Also makes the delete service's undo explicit: it re-saved a pre-delete
snapshot, which happened to clear the stamp but would silently revert any
change made during the undo window. It now calls restoreConfig.

Supersedes the SeedTombstoneStore from #3573. Deleting an AI config now stamps
deletedAt on the row and re-saves it, so the row itself is the tombstone.

The ledger was the wrong shape. It lived in settings.sqlite while the config
lives in ai_config.sqlite, so no transaction could span a deletion and a
seeding check — the race CodeRabbit raised, which I could only mitigate with a
post-pass reconciliation. It was local state, so a device that never observed
the delete could re-seed and sync the row back. And two stores writing the same
row could lose an identity, which needed a serialization queue that itself
shipped with a cross-database bug.

The field costs neither of the things I assumed ruled it out. ai_configs stores
the whole config in a serialized TEXT column, so a new freezed field lands in
that JSON and schemaVersion stays 1. SyncMessage.aiConfig already carries the
whole config, so the deletion replicates on the existing path. It also matches
how the journal domain deletes synced entities (CategoryRepository).

Reads split by intent: getConfigById/getConfigsByType hide deleted rows by
default, the seeding passes ask for them so a deleted row reads as present and
blocks re-creation, and watchConfigsByType always filters. Two paths keep
hard-deleting through hardDeleteConfig — removeOrphanedDefaultSeeds and the
provider cascade — because both want their rows back later.

Deletes SeedTombstoneStore, its test, seedTombstoneStoreProvider, the settings
key, recordTombstone, the mutation queue, and the mid-pass reconciliation in
both seeding passes.

Also makes the delete service's undo explicit: it re-saved a pre-delete
snapshot, which happened to clear the stamp but would silently revert any
change made during the undo window. It now calls restoreConfig.