[matt-edmondson]

Fixes #247
Fixes #248

Both issues are gaps in the create-before-init path that #206 made supported, and their triage asked for one fix, so this PR covers both.

What changed

KeybindingManager now remembers the profile CreateDefaultProfile() makes before InitializeAsync() has run, along with the name and description it gave it. InitializeAsync() then reconciles that placeholder with what is stored:

• A profile created before InitializeAsync() loses the stored profile's name and description, and resolves duplicate stored chords to a different command than a fresh load (gaps in #206) #247, name lost. If a stored profile has the same id and the placeholder still has the name and description CreateDefaultProfile gave it, it takes the stored profile's name and description. The next SaveAsync no longer writes "Default / Default keybinding profile" over the user's.
• A profile created before InitializeAsync() loses the stored profile's name and description, and resolves duplicate stored chords to a different command than a fresh load (gaps in #206) #247, duplicate chords. MergeStoredBindings copies stored bindings with SetStoredChord, as a fresh load does. Before, it used SetChord and kept only the first binding per chord in file order. Legacy data that binds one chord to several commands now resolves in ordinal command-id order (a.cmd in the issue's example) and keeps both bindings on disk. In-memory bindings still take precedence: a stored binding is skipped when its command or chord is already bound in memory.
• A "default" profile the user deleted comes back for good when CreateDefaultProfile() runs before InitializeAsync() (#189 returns on the #206 path) #248, deleted default comes back. If other profiles are stored but none has the placeholder's id, and the placeholder is still untouched (no bindings, not renamed, never saved), init drops it. If the placeholder was the active profile and nothing stored gets activated, init activates the first profile by ordinal id, which is what CreateDefaultProfile would have done had it run after loading. A placeholder the app has already bound or renamed is kept.

This follows the triage note on #248: it reconciles inside InitializeAsync rather than throwing before init, so the call order #206 supports keeps working.

Tests

New tests in ProfileCreatedBeforeInitializeTests:

• ProfileCreatedBeforeInitialize_TakesTheStoredNameAndDescription: the rename survives a create-before-init launch, a save, and a reload
• ProfileCreatedBeforeInitialize_ResolvesDuplicateStoredChordsAsAFreshLoadDoes: the issue's duplicate-chord fixture resolves to a.cmd and keeps both bindings after a save
• DefaultProfileCreatedBeforeInitialize_DoesNotBringBackADeletedDefault: the A "default" profile the user deleted comes back for good when CreateDefaultProfile() runs before InitializeAsync() (#189 returns on the #206 path) #248 sequence ends with only vim, in memory and on disk
• DefaultProfileCreatedBeforeInitialize_ActivatesAStoredProfileWhenItsPlaceholderIsDropped
• DefaultProfileCreatedBeforeInitialize_IsKeptOnceTheAppHasBoundIt: guard test; it passes before and after the change

I reverted KeybindingManager.cs and reran the class: the first four tests fail without the fix and pass with it. The full suite passes: 439 tests, 0 failures. dotnet format --verify-no-changes is clean on the changed files.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud