kona: Follow-up cleanups from Karst hardfork PR #19372

Follow-up items identified during review of #19372 (Karst hardfork support) that were out of scope for that PR. All originally flagged by @geoknee.

## 1. Use `is_first_karst_block()` helper in derive and sequencer code

- **File:** `rust/kona/crates/protocol/derive/src/attributes/stateful.rs`
- [PR comment](https://github.com/ethereum-optimism/optimism/pull/19372#discussion_r2882953293)

The first-block detection currently uses the manual pattern:

```rust
if self.rollup_cfg.is_karst_active(next_l2_time) &&
!self.rollup_cfg.is_karst_active(l2_parent.block_info.timestamp)
```

This could use self.rollup_cfg.is_first_karst_block(next_l2_time) instead, which already exists and is more readable. Same pattern applies to the other hardfork
first-block checks above it.

## 2. Simplify test override timestamps in CLI flag tests

- File: rust/kona/bin/node/src/flags/overrides.rs
- [PR comment](https://github.com/ethereum-optimism/optimism/pull/19372#discussion_r2882922734)

The test uses realistic-looking timestamps (1740000000, 1745000001, 1750000000, 1755000000) which make it hard to visually verify time ordering. Using simple sequential
values like 10, 20, 30, ... would be clearer.

## 3. Fork activation chaining semantics differ from op-node/op-geth

- File: `rust/kona/crates/protocol/genesis/src/rollup.rs` (is_jovian_active() and similar)
- [PR comment](https://github.com/ethereum-optimism/optimism/pull/19372#discussion_r2882959407)

In kona, `is_jovian_active()` returns true when Karst is active even if `jovian_time` is not explicitly set (because it chains to the next fork). This differs from how
`op-node` + `op-geth` handle hardfork activation, where each fork's activation is independent.

Concern: this could be a footgun — a fork reports as "active" even when it was never explicitly scheduled. It also raises questions about portability of hardfork
configs between `op-node` and `kona-node` (e.g. from the superchain registry).

In practice this is safe today because hardforks are always scheduled in order and never skipped, but aligning the semantics would be more robust.

cc @theochap @sebastianst

Read the three named areas: stateful.rs for first-block helpers, overrides.rs for timestamp fixtures, and rollup.rs for fork activation methods. Compare the activation behavior with the referenced op-node/op-geth semantics before changing it. Done means the helper usage and test values are simplified, and fork activation behavior is aligned or the intended semantics are documented and verified by relevant tests.

Written by the indexing model from the issue text.