wiretap v0.2.13

wiretap v0.2.13

This patch makes Linux credential storage follow the desktop's configured
Secret Service default collection.

The default collection is authoritative

Wiretap now uses ByteNess/keyring for native credential storage. On Linux,
Wiretap first calls Secret Service's standard ReadAlias("default") method,
validates the returned collection path, and passes the resolved concrete name
to ByteNess. This means the desktop configuration—not an application-specific
assumption—decides where credentials live.

Wiretap no longer:

• prefers a collection merely because it is named login;
• treats its wiretap service name as a collection name; or
• creates a new collection when the configured default already exists.

Relay-admin and client credentials continue to share the wiretap service and
remain isolated by distinct item keys inside the operating-system collection.

Existing client migration remains available

The existing protected-file migration is unchanged. If
relay-credentials.json contains a plaintext client_token, the first load
tries to store it in the resolved default keyring. After a successful write,
the file is rewritten with only the client identity, projects, and opaque
keyring reference. If the keyring is unavailable, the mode-0600 file remains
the fallback so the relay client can continue operating.

Wiretap deliberately does not inspect or copy credentials from other keyring
collections. A token saved by v0.2.12 in a separate login collection should
be re-entered or restored through the protected credentials file before that
collection is removed. Saved relay-admin profiles should be saved again after
connecting with their admin token.

Verification

The Linux integration suite resolves the live default alias, performs a full
Set/Get/Delete round trip, confirms the item exists in that exact collection,
and asserts that the collection inventory does not change. Unit coverage also
validates encoded collection names such as Default_5fkeyring.

Full changelog: v0.2.12...v0.2.13