Track SSH agent key ownership by the root group uuid

[underclockeddev]

Fixes #13704. Supersedes #13705, per the discussion there.

SSHAgent recorded which database added each key by Database::uuid(), which is generated for every Database object and never stored in the file. Anything that builds a new Database object for the same file orphaned the keys: locking no longer removed them, and unlocking was refused as an ownership conflict. This change keys ownership on the root group uuid instead, which is stored in the file, as suggested in #13704.

Two paths that build a new object are fixed by this:

• a reload from disk (reloadDatabaseFile), for example when a sync tool delivers an edit made on another machine. This includes the hardware-key case: the reload first fails with the key unplugged, then completes once the key is back.
• an unlock dialog (for example one opened by a Secret Service request) that is completed after the main window has already unlocked the same database. unlockDatabase() then replaces the database with a second object.

Behaviour change: two copies of the same file open at once now share ownership of their keys instead of refusing each other. Either can add them, and locking either removes them. testTwoOpenCopiesShareKeys covers this.

The investigation, patch and tests were written with Claude Code (Claude Opus 5.5) and reviewed by me before submitting.

Screenshots

N/A

Testing strategy

• Three new tests in TestSSHAgent: testRemoveOnLockAfterReload, testReaddOnUnlockAfterReload, testTwoOpenCopiesShareKeys. With only the tests applied to develop, all three fail. With the fix, they pass.
• Full ctest suite (non-GUI): 46/46 pass on develop and with this change.
• End to end, the reload repro from SSH agent: after the database file is reloaded from disk, lock no longer removes keys and unlock no longer adds them #13704 against the built keepassxc and keepassxc-cli: on develop the key stays after lock and is not re-added on unlock; with this change both work, and the controls without an external edit behave the same on both builds.
  Script: https://gist.github.com/underclockeddev/4051fb85ea881fcdecc2841eacc692d1
• The same change backported onto 2.7.12: a scripted reload case, and the unlock-dialog case above driven by hand with a YubiKey. In both, the lock afterwards removed the key. Both left the key on unpatched 2.7.12.

Type of change

• ✅ Bug fix (non-breaking change that fixes an issue)

[droidmonkey]

Beautiful