chore(deps): bump gloo-timers from 0.3.0 to 0.4.0

[dependabot]

Bumps gloo-timers from 0.3.0 to 0.4.0.

Release notes

Sourced from gloo-timers's releases.

gloo-timers 0.4.0

MSRV updated to 1.82

Changelog

Sourced from gloo-timers's changelog.

Version 0.4.0

• Update MSRV to 1.82 (#505) by @​martinfrances107

Commits

• c8feeb1 chore: release gloo-timers 0.4.0
• d69fcff chore: release gloo-net 0.7.0
• 7a57df3 chore: release gloo-file 0.4.0
• 2685476 fix: correct gloo-history category slugs
• b1d5129 fix: correct gloo-storage category slugs
• 8316f33 fix: correct gloo-render category slugs
• 0734551 chore: release gloo-console 0.4.0, gloo-dialogs 0.3.0, gloo-events 0.3.0, glo...
• e6280d4 chore: release gloo-utils 0.3.0
• cca8089 chore: release gloo-worker-macros 0.2.0 and gloo-worker 0.6.0
• a8af99c chore: update rust dependencies (#536)
• Additional commits viewable in compare view

[chainTe]

Security Review

Result: No reportable security findings.
Reviewed range: bc361aaaa40d1394b83e6a1808869b0b06c48c13..38cea875951fb0cd1177e450a13bdd6f6891bc2c

Validation:

• Existing broad tests were not run locally; CI is expected to cover them.
• Targeted cargo metadata --locked --format-version 1 fails at PR head because the lockfile wants gloo-timers 0.4.0 while crates/fiber-lib/Cargo.toml still requires gloo-timers = { version = "0.3", features = ["futures"] }.
• The same locked metadata command succeeds on the base branch control.
• The cached gloo-timers 0.3.0 and 0.4.0 src/ and tests/ trees are byte-identical; the change is metadata/minimum-dependency-version only.

Notes:

• This is not an attacker-exploitable security issue, but it is PR-blocking build integrity: --locked/--frozen builds fail, and an unlocked build re-adds gloo-timers 0.3.0, making the bump ineffective.
• Fix by updating the wasm32 manifest dependency to gloo-timers = { version = "0.4", features = ["futures"] } and regenerating Cargo.lock, or close/recreate the Dependabot PR.