fix(welcome): remove the sample database journal files on reset

[datlechin]

Summary

Reset Sample Database replaced Chinook.sqlite and left its -journal, -wal and -shm files next to the fresh copy. SQLite treats a leftover hot journal as an unfinished transaction and rolls it back into whatever file now has that name, and it replays a leftover -wal the same way. So a reset could hand back a sample that was neither the original nor the user's edited copy. #2983 fixed the iOS installer. This is the macOS side of the same bug, plus the same bug in the remote-file fetch it shares a rule with.

Root cause

Two places replace a SQLite file and decide which of its sidecars to delete:

1. SampleDatabaseService.resetToBundled removed only the main file. installIfNeeded removed nothing, so an install over a missing database adopted journal files that a failed reset had left behind.
2. RemoteDatabaseFileTransfer.clearStaleSidecars kept every sidecar the fetch plan listed, not the ones the fetch actually downloaded. A -wal the server checkpointed away, or a -journal whose transaction ended between planning and fetching, was never downloaded, so the local file with that name still belonged to the previous copy and was kept.

DatabaseFileLayout.staleAfterReplaceSuffixes also left out -journal for the SQLite family.

Changes

• DatabaseFileLayout.sqliteFamily.staleAfterReplaceSuffixes now includes -journal.
• SampleDatabaseService removes the main file and every sidecar before it copies, on both reset and install. When the installed database is still there, install never touches its journal files.
• fetchSidecars returns the suffixes it downloaded, and clearStaleSidecars keeps only those. A RemoteFileSource protocol over LibSSH2SFTPSession lets the tests drive a server whose sidecar disappears between plan and fetch.

Tests

SampleDatabaseServiceTests, RemoteDatabaseFileTests, RemoteDatabaseFileCorrectnessTests: 37 cases, all passing on the rebased tree. The new cases open real SQLite files with a hot journal and a live -wal and check that a reset never rolls back or replays them over the fresh copy.

• A reset removes the rollback journal, write-ahead log and shared-memory index.
• A reset leaves no hot journal to roll back and no write-ahead log to replay.
• An install clears journal files that a missing database left behind, and never touches those of an installed one.
• A reset while the sample is open throws connectionInUse and leaves the files alone.
• A fetch that downloaded no sidecar clears all three. A direct copy keeps a journal it fetched and clears one the server had dropped by fetch time.

No UI automation: the change is inside a file operation. The user flow (Reset Sample Database in the welcome window) is unchanged.