fix(system-info): guard compute-pressure observer behind permissions policy

[antsukanova]

Description

• Prevent SystemInfo imports from starting CPU pressure observation when the document permissions policy denies compute-pressure.
• Handle observer construction and asynchronous observe() failures so restricted cross-origin iframes do not produce unhandled promise rejections.
• Preserve CPU pressure monitoring when policy access is allowed or policy inspection is unavailable.

Testing

• yarn test
• Manually loaded the linked package in a cross-origin test iframe. Both denied and allow="compute-pressure" cases completed with zero unhandled rejections.

This change implements...

• A new feature
• A bug fix
• Other (please specify):

Is this a breaking change?

• Yes
• No

I certify that...

• All relevant unit and integration tests have passed and/or have been updated according to this change.

Generative AI (GAI) Usage Disclosure

Reference: Cisco GAI Coding Guidelines

• Cisco approved GAI tool/IDE was used for coding - eg: VSCode, Cursor, Windsurf, Codex, Claude code
• No GAI - Code was written entirely manually without GAI assistance

If a GAI tool/IDE was used then select the category that best describes GAI usage in this PR:

• Manual Draft with GAI Refinement - I/we created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code) (Default)
• GAI Draft with Manual Customization - GAI tool was used to create a draft that I/we subsequently customized or modified.
• GAI Generated Code - Code was generated entirely by GAI

Additional GAI Usage Details (Optional):

[wiekiera]

Overall looks fine for me, except testing stuff - there are many conditions in setPermissionsPolicy function depends on testing scenarios that can make hard to debug and tell whats gone wrong if something fails. In my opinion the test scenario should be simple and readable, even if some code overlaps with other tests. This is not the time for doing it when customer is waiting for the fix. I will let you know if it's working - need to test it on local environment then we can merge it.

[wiekiera]

Tested - seems It won't break anything existing

[antsukanova]

@wiekiera Thanks, fair point. The setup is more involved because SystemInfo creates the observer during module import, so each case requires a fresh module load and mocked browser globals. I used setPermissionsPolicy to keep the individual tests focused, but I agree that the scenario mapping adds some complication.
These tests will need revisiting with the planned API change anyway, so we can simplify this setup then. 🙌