Excessive disk writes due to tab lockout ping and rageshake log persistence

### Steps to reproduce

1. Run element-web in Firefox
2. Monitor writes by `Firefox [LS Thread]` and `[Indexed~O \#xxx]` using e.g. `iotop -a`

### Outcome

#### What did you expect?
No writes when nothing is happening.

#### What happened instead?
A surprising amount of writes.

This problem seems worse recently, perhaps due to some changes in element-web, or perhaps changes in newer versions of Firefox.

1. The hack for #25157 writes the "react_sdk_session_lock_ping" key constantly to local storage. In https://github.com/element-hq/element-web/commit/f3653abe926c8486f0177f2ef05b0cac0eab5f01 the write interval was decreased. Due to what I can only characterise as some write-amplification that I did not explore, this one thing causes high tens of megabytes of local storage writes per hour.
2. Rageshake defaults to recording all console messages into the IndexedDB logs database if there is a report endpoint on the homeserver; there are new and relatively large matrix_sdk_crypto trace messages that did not exist in the past which may be making this worse.

For (1), I think you can just use BroadcastChannel to detect whether another client in the same browser is still alive or not instead of polling to see if the ping time key has been changed. For (2), consider not persisting logs by default, using more aggressive filtering (do you really need all the FetchHttpApi sync requests for debugging?), or add an option to disable log persistence for people who really, genuinely are not going to shake their rage at you.

By replacing `localStorage.__proto__.setItem` with a filtering function to ignore the ping key I can confirm that the excessive LS Thread writes go away, and by restoring the original `console` functions so they aren’t redirected to rageshake I can confirm the excessive IndexedDB writes also go away.

I hesitate to send this since I do recognise that maybe 400GiB per year per instance does not seem like much in the grand scheme of things, but at the same time it is that kind of silly waste that accumulates into a problem as consumer SSD durability continues to go down. So I guess I will send this and leave it up to you to decide whether you care. :-)

### Operating system

Debian Linux

### Browser information

Firefox 141

### URL for webapp

app.element.io

### Application version

Element 1.11.109, Rust SDK 0.13.0 (f64839e), Vodozemac 0.9.0

### Homeserver

matrix.org

### Will you send logs?

No

Search for the `react_sdk_session_lock_ping` localStorage key and the rageshake IndexedDB logs database, then trace how the tab lockout ping and console persistence are scheduled. Reproduce the idle writes in Firefox while monitoring storage activity. Done means idle use no longer causes excessive writes and log persistence behavior is appropriately controlled.

Written by the indexing model from the issue text.