Make the e2e suite pass, and fix the data loss it was reporting

[vmillet-dev]

Two commits, one subject: the end-to-end suite fails on the Ubuntu leg, and it is
right to.

1 — A note closed right after it was written loses its body

02-note-lifecycle › reads the note back from the database on a fresh front end
Expected: "openssl req -new -key staging.key -out staging.csr"
Received: ""

Not flaky infrastructure. requestClose() fires the title, the source and the
content commits and then closes, in the same turn. Each commit suspends on
resolve() while the draft turns into a row; closeOverlay() runs before they
resume and clears _selectedNote.

By the time they do resume, find() has nothing left to answer with: the draft
is gone, the selection is gone, and the only fallback is the canvas view —
which is one round trip behind the write that created the note. The commits
resolved to null and were dropped in silence. The note kept the title its
creation payload carried and lost the body typed after it.

Windows wins that race, Linux loses it, which is what made a data-loss bug read
as an unreliable test.

NotesStore now remembers the row the draft became, until the editor is pointed
at another note. find() consults it after the selection and before the view,
and persist() keeps it current.

Reproduced, not guessed. The new test plays that sequence — commit, close in
the same turn, let it settle. With the lookup removed:

× lands the commits the close itself fired
AssertionError: expected "update" to be called with arguments: [ Any<String>, …(1) ]
Number of calls: 0

2 — The e2e profile was only half wiped

resetProfile() wiped app_data_dir() and called it clean. Since #99 that is no
longer the whole profile: tauri-plugin-window-state writes .window-state.json
under app_config_dir(), and on Linux those are two different directories.

So the window geometry survived every wipe there, and a run opened on the window
the run before it closed with. Windows cannot tell the two apart — both are
%APPDATA%\<id> — which is why the hole never showed, and CI never met it either:
its runners are new each time. Both are wiped now, de-duplicated so Windows still
does one pass, and the guard names whichever survived. docs/architecture.md says
so where it states the rule.

Checked

npm test 960 passing, npm run lint clean, the suite 15/15 in 3:52 locally.
On CI the first three attempts of the earlier commit were green on both legs;
the count restarts here because this branch moved, and five consecutive green runs
are what this merges on.

⚠️ Worth knowing while reading those runs: test-e2e is continue-on-error, so a
failing E2E leg still reports the whole run as success — which is how the defect
above sat on main across three merges. #108 tracks that.

🤖 Generated with Claude Code