feat(keyring-controller): add keyring.fingerprint support

[ccharly]

Explanation

Adding a new way of identifying keyring with a "fingerprint". This would allow to have keyring-defined identifiers (determinist identifiers), that can be used to retrieve the keyring afterward (e.g Snap ID once we start splitting the Snap keyring in multiple keyrings, Money keyring that are sort-of proxy around HD keyrings).

References

N/A

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Touches keyring creation/restore and selection logic; incorrect fingerprint implementations or collisions could affect keyring lookup behavior, though failures are guarded by skipping and logging.

Overview
Adds optional, builder-defined keyring fingerprinting: KeyringBuilder can now expose getFingerprint(keyring) and KeyringMetadata gains an optional fingerprint field populated on keyring creation and recomputed during vault restore (errors are caught and logged, leaving it unset).

Extends withKeyring to support selecting a keyring via { fingerprint: string } in addition to existing selectors, and adds test coverage for fingerprint storage, restore recomputation, error handling, and fingerprint-based selection.

Updates the package changelog to document the new fingerprint capability and selector variant.

^{Written by Cursor Bugbot for commit 59bab8d. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Stale fingerprint not cleared during keyring restore

Low Severity

In #restoreKeyring, the comment says "We recompute the fingerprint," but if the builder no longer provides getFingerprint (or it throws), #getSafeFingerprint returns undefined and the conditional if (fingerprint !== undefined) skips the update — leaving any previously-persisted fingerprint from the vault intact in metadata. This means a stale fingerprint survives restoration and remains usable via withKeyring({ fingerprint: '...' }), even though the builder can no longer produce it. To truly "recompute," the old fingerprint would need to be explicitly cleared when the builder no longer supports fingerprinting.