bug(storage): keyring secrets collide across data profiles with the same connection id

[ZhuchkaTriplesix]

Summary

Connection secrets are stored in the OS keyring under keys built only from the connection id (querya.v1.conn.<id>.password, querya.v1.conn.<id>.connection_string), while the SQLite profile database can live in different places: the installed profile, a portable profile (QUERYA_PORTABLE / QueryaData sidecar), or the legacy pre-#385 profile (com.example.querya_desktop). AppDataRoot notes that secrets are not redirected.

Two profiles that both have a connection with the same id therefore share keyring entries. Saving a connection without a password in one profile (writeForConnection deletes the key when the value is null or empty) removes the password of the other profile's connection with that id; saving one with a password overwrites it.

Repro

1. Installed profile has connection id 5 with a saved password.
2. Start a portable build, add any connection that gets id 5 without a password.
3. Back in the installed profile, connection 5 has lost its password.

Found while running a benchmark against a throwaway profile directory: its demo connection (id 1) cleared querya.v1.conn.1.*, which belonged to the legacy profile's PostgreSQL 127.0.0.1:5432/querya.

Scope

• Namespace keyring keys by profile (for example a random profile id stored in the profile DB), with a one-time migration of existing keys for the current profile.
• Tests for two profiles with overlapping connection ids.

[ZhuchkaTriplesix]

Resolved by #993 (already merged into dev; not auto-closed since this repo's default branch is main and PRs merge into dev).