Cardano Updates

The YAML knob `vote-threshold: u64` (absolute count, mode-dependent
in meaning) is replaced by `quorum-weight-fraction: f64` (always a
fraction). The absolute threshold is derived at config build from
`quorum_weight_fraction × expected_total_weight`, with the
denominator per mode: PV+NPV seats (WfaLs), node count (Everyone),
total active stake (TopStakeFraction).

Default kept at 0.6 (legacy 300/500) in config.default.yaml to
preserve existing-experiment numerics; code default 0.75 (CIP-0164).

For TopStakeFraction, `try_vote_for_endorser_block` emits the
voter's own stake as the per-EB weight (rather than 1). The quorum
check is unchanged in form — `Σ weight ≥ vote_threshold()` — because
the threshold method now returns stake-denominated values.

`SimConfiguration::build` enforces σ_c > τ for TopStakeFraction and
bails with a clear error referencing the PR. Two new tests:
`top_stake_fraction_uses_stake_weighted_quorum` (per-voter weight =
stake, low-stake majority does NOT certify) and
`sim_config_rejects_top_stake_fraction_when_sigma_c_le_tau`.

`shared_consensus.rs` adapter: `derive_quorum_fraction` collapses to
a passthrough; expected_total_weight uses the new helper.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Quorum is now `Σ voter_stake ≥ τ × total_active_stake` under
StakeCentile committee selection. WfaLs and EveryoneVotes keep their
head-count semantics. The aggregator's per-voter weight unit is now
mode-polymorphic — seats for WfaLs, 1 for Everyone, voter stake for
StakeCentile — and the denominator returned by
`committee::expected_total_weight` matches.

`wfa.rs` is renamed to `committee.rs` since wFA^LS is one of three
schemes now, not the only one. `voter_weights` and the `weight`
parameter widen from u32 to u64 so stake values fit; quorum
comparisons follow.

`ElectionsConfig::validate()` enforces σ_c > τ at startup for
StakeCentile (PR #1196 §"Quorum as a stake threshold"); both the
sim-rs adapter and net-rs net-node panic on a misconfigured set.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Replace the central decsision thread by having server threads coordinate
between them by blocking on STM actions.

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

  This allows to properly encapsulate those fields which MUST NOT be accessed directly inadvertently. Given that it is very easy to so (and effectively hard to keep track of), moving them in a separate module encapsulated as private field in a struct gives us the strong compiler guarantees needed. Defining Deref and DerefMut also makes it transparent to use from the parent module; yet preserves the encapsulation we need.

  Note that this made apparent an inconsistency in terms of protocol parameters and governance activity between validation and block application. This is now properly handled.

Signed-off-by: KtorZ <[email protected]>

This allows us to keep track of the total weight against a threshold to
certify (also in the visualization).

  This is large because it touches quite many parts and I had to
  untangle store side-effects in the middle of various places. The
  general idea is rather simple, though:

  - The epoch transition no longer mutates the store directly;

  - Instead, the transition is entirely read-only; and produces three
    distinct 'pending' updates:
    - rewards payouts
    - pools updates (i.e. de-registration & parameters changes)
    - governance results (ratified & expired proposals, withdrawals, ...)

  - These updates are not immediately applied since they cannot be
    considered stable until later in the epoch. Instead, they're stashed
    in the ledger state object;

  - Later, once the results from the previous can be considered stable
    (cf stability window); we can flush the updates and begin the
    rewards calculations for the next epoch.

  What's left TODO from there:

  - We must ensure that access to various moving parts of the ledger
    state (e.g. protocol parameters, governance activity, etc...) are
    not done directly on the struct fields; but rather go through
    helpers that take care of applying the transient state if there's
    any. So for example a `.protocol_parameters()` will first look at
    any available governance update, and if any, use that in priority.

    Similarly, when consulting the balance of an account, we would first
    have to look for any unapplied rewards.

  - Refunds and withdrawals from governance are not checking that
    accounts still exists. They simply stash the update. But in
    practice, like for pools; we would also need to send uncollected
    money flow to the treasury. Same for pool refunds.

  - More importantly, updates are not currently flushed to disk. That
    crucial part is missing and will happen in a future commit. The plan
    for now is to do it "naively" and flush all updates at once as soon
    as we enter the stable part of the epoch. Later, we can split the
    update over multiple slots to avoid keeping the ledger busy for too
    long.

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>