Fix falling back to data.json when keyring is available

[tangowithfoxtrot]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-16856

📔 Objective

Fix #8651 and similar issues where, even if a secure storage keyring is available, we were falling back to data.json. We can't assume that the keyring is always unlocked when a user is logged in on Linux. This change ensures that we send an unlock prompt if the keyring is locked.

📸 Screenshots

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[github-actions]

Checkmarx One – Scan Summary & Details – 769ffa47-8aa1-4c01-8ad0-4e9e8976033c

Fixed Issues

Severity	Issue	Source File / Package
	Client_Privacy_Violation	/libs/vault/src/components/decryption-failure-dialog/decryption-failure-dialog.component.html: 17

[quexten]

LGTM

Non-blocking question to consider: Do we need to consider any retry logic here if the user enters the wrong password, or do gnome-keyring and kde wallet take care of this?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 34.14%. Comparing base (65a27e7) to head (7d4dbf8).
Report is 4 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12760      +/-   ##
==========================================
- Coverage   34.15%   34.14%   -0.01%     
==========================================
  Files        2936     2937       +1     
  Lines       90230    90332     +102     
  Branches    16940    16958      +18     
==========================================
+ Hits        30820    30846      +26     
- Misses      56955    57031      +76     
  Partials     2455     2455              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tangowithfoxtrot]

Non-blocking question to consider: Do we need to consider any retry logic here if the user enters the wrong password, or do gnome-keyring and kde wallet take care of this?

Good point. The keyring will reprompt if you enter the wrong password or decline the unlock request, but then we keep re-requesting the unlock anytime we do something with the access/refresh token, which is definitely not great. Let me see what needs to be done to make that a little nicer...