* 0820dev

* maybe

* i should see what's going on with react moment

* Flaky test test_ensure_task_limit_window_passed

Try to make the test less flaky by making the iteration wait time equal to the
exception_limit_window and reducing the exception_limit from 3 to 2. This
should still catch the case in question, but be less timing dependent.

* Use longer delay in CI to make race harder to hit

* Send a "reconnect" hydrate whenever the socket reconnects

* "reconnect" hydrate doesn't reset client storage or trigger on_load, it just
  returns the latest complete state dict
* this event is driven by the frontend after the socket connects
* update `link_token_to_sid` to NOT emit a delta when the sid changes for a
  token; the client will be informed of this during the initial hydrate or
  "reconnect" hydrate.

Fix #5963

* fix lost+found test case

* make sure there is a hydrate event before we assume

if the app is stateless, then presumably we don't end up connecting a websocket
at all, so we wouldn't hit this code. also if `initialEvents` was empty for
whatever reason, then the app probably wouldn't work... but lets make it look a
bit safer.

* oops mocked app isn't based on real app

Make the oplock hold time configurable and drop the default down to 50% of the
configured lock timeout to avoid lock expiration between the lease breaker
sleep ending and the coroutine actually getting scheduled for execution.

When calling a method on an arbitrary wrapped object, rebind it's `self` as the
mutable proxy so changes made inside the method are also tracked.

(Previously only wrapped `Base` instances had in-method tracking).

* update codeql to v4 -- maybe that helps?

* codeql-config: update scan paths

* try different include path patterns

* add .github to codeql for workflow scanning

It turns out that just rehydrating and not also re-running the on_load handlers
can leave applications in a bad state; particularly when their background tasks
exiting are predicated on the `sid`, that will change on reconnect, but without
an on_load, no mechanism is there to restart the tasks.

If the socket_record expires in redis, but the instance managing it is still
alive, then re-link the token to the sid.

For `del` and `evicted`, do not re-link the token as this is an explicit
disconnect.