fix: confirmation badge - max unlock request badge size

[Prithpal-Sooriya]

Description

I don't see a reason for the unlock counter to be >1. All unlock counts will vanish as soon as the wallet is unlocked.
Otherwise I am open to adding a larger bounds (but this will ideally prevent the counter from having 1000+ count on the fox counter for confirmations)

Related issues

Fixes: #26064

• This prevents snaps from constantly increasing the unlock request badge size (e..g prevent 1000+ count on the confirmations badge)

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[Prithpal-Sooriya]

Context: This waitingForUnlock is an array of promises from requests internally (any maybe externally) that require the wallet to be unlocked. As soon as the wallet is unlocked, all of these promises get resolved.

From a UI perspective, I don't see why we need to have more than 1 unlock count - especially as all the requests will get resolved once the wallet is unlocked.

Otherwise we can add a larger bound here. This will prevent the unlock requests count from growing (e.g. prevent 1000+ count on the confirmations badge)

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 69.94%. Comparing base (30dce33) to head (537d8a5).
Report is 338 commits behind head on develop.

Files	Patch %	Lines
app/scripts/background.js	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #26162      +/-   ##
===========================================
- Coverage    69.94%   69.94%   -0.00%     
===========================================
  Files         1409     1409              
  Lines        49794    49795       +1     
  Branches     13769    13769              
===========================================
  Hits         34825    34825              
- Misses       14969    14970       +1     

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

[metamaskbot]

Builds ready [537d8a5]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5
  • common: 0, 1, 10, 2, 3, 4, 5, 6, 7, 8, 9
  • content-script: 0
  • offscreen: 0
  • ui: 0, 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (317 ± 299 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	64	121	95	18	8
		domContentLoaded	9	51	24	12	6
		load	42	2304	317	624	299
		domInteractive	9	51	24	12	6

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 12 Bytes (0.00%)
• ui: 0 Bytes (0.00%)
• common: 0 Bytes (0.00%)

[bschorchit]

This might already be part of the PR, but adding this here in case it's not: we should also prevent the notification window from popping up to users requesting them to unlock when those calls are made while the wallet is locked.

[Prithpal-Sooriya]

This might already be part of the PR, but adding this here in case it's not: we should also prevent the notification window from popping up to users requesting them to unlock when those calls are made while the wallet is locked.

Good callout - particularly for the issue line:

After reloading / turning the extension OFF->ON popup appears automatically

This may be pre-installed snaps related - this will come under a separate notifications related PR. Will investigate to see if it resolves the issue.