Use `RootProvider::connect` so it automatically detects the URL scheme
and sets up the appropriate clients. This enables support for web
sockets rather than only supporting http/https URLs.

#3018)

# Description
The main goal of this change is to allow engine processing to continue
after block building has been initiated but before it has been sealed.

This is accomplished by:
- Updating the `EngineActor` to
    - Make the `BuildTask` only initiate block building
    - Add a new `SealTask` to seal and insert the initiated block
- Updating the `SequencerActor` loop to 
    - Seal the last block and start the next block
    - Dynamically set the loop interval to account for sealing duration

Importantly the `SequencerActor`'s `build_block` function no longer
starts and completes block building in a single call but rather seals
the last block if there was one, and starts the next. This means that
the time spent waiting for the next tick will be _during block
building_.

This also changes the `EngineTask` pattern within the `SealTask` such
that if there was a caller (i.e. there exists a `Sender` to use to relay
results), the task may not be retried if there is a "temporary" task
error. While this diverges from existing patterns, it is a meaningful
step toward #3021, which aims to pull logic out of the engine and into
the appropriate actor. This gives the Sequencer more insight into and
control over block building and timing.

## Considerations
This PR creates a number of possible race conditions. One race condition
that did not previously exist but has been introduced and mitigated is
`Build` (FCU) -> `Reset` -> `Seal`.

A worthwhile exercise for a reviewer is to consider the other possible
race conditions introduced and evaluate the feasibility of them
occurring and impact if they happen.

## Testing
While this PR is ready to review and passes existing e2e and acceptance
tests, a byproduct of breaking apart the `BuildTask` is a number of
possible race conditions. This PR aimed to address a number of them
(e.g. detecting if the unsafe head changed between `Build` and `Seal`
operations and retrying), but a worthwhile exercise will be to:
1. List all possible `EngineActor` task race conditions that could
result from this change
1. Define expected behavior for each of those conditions
1. Confirm via unit tests that behavior matches expected behavior.

There is also value in unit testing the logic in the different functions
within `SequencerActor` and the affected `EngineActor` tasks.

Unfortunately the act of making the `SequencerActor`, `EngineActor`, and
`EngineTask`s unit testable is a considerable amount of work. A
different PR will be created, branching off of this PR to attempt that.
This PR _can_ be merged as is, as it meets current standards, but
another reasonable option is to wait until `kona` is more unit testable
and unit tests exist to demonstrate that the changes work as intended.

## Other 

Fixes #2978
Relates to #2848, #3021

The Signer error constructed in block validation inverted the semantics
of expected and received.
Expected should be the configured unsafe block signer, while received is
the address recovered from the message signature.
This fix swaps the fields to match code comments and conventional error
reporting, ensuring logs and diagnostics are accurate.

https://docs.rs/kona-registry/latest/superchain/struct.OPCHAINS.html -
broken
https://docs.rs/kona-registry/latest/kona_registry/struct.OPCHAINS.html
- works

## Description

Allows to pass in bootnodes in enode format in `kona-node`'s CLI.
Somewhat simplify and cleanup the code to populate the peer bootstore at
startup

@jelias2

# Description 
* Adds logfmt to kona node available logging formats
* Update just file to load docker image into local docker instance after
docker buildx with load argument

## Description

Bump alloy and revm dependencies.

## Description

Update SCR. Commit:
ethereum-optimism/superchain-registry@59e22d2

The JUnit strategy seems to be buggy so let's use the naive strategy.

Add the ability to customize the embedded chain configs provided by
kona-registry.
Custom chain configs are merged into the superchain configs without
conflicts. Any conflicts found will result in a build failure. The merge
operation is idempotent. The resulting configs generated in the etc
directory have a minimal diff, allowing users to easily verify the
changes introduced.

Breaking changes:
- A couple kona-registry types were moved to kona-genesis so that the
kona-registry build script could use the types to parse custom chain
configs.

---------

Co-authored-by: theo <[email protected]>

…ode (#3037)

## Description

Tries to cache cargo build dependencies for reth as a submodule in CI
Tries to cache build dependencies for go submodules in CI
Remove claude code