batch_operator: report the group actually on duty when logging a non-election

[heifner]

Follow-up to #573 (closed). That PR's backfill regressed flow-batch-operator-termination and carried two unresolved [P1]s, so it was closed rather than iterated. Two items surfaced during that investigation were real and independent of the backfill; this PR carries the one that is unambiguous.

The fix

The not-elected log printed epoch_index % 3 as active_group:

ilog("batch_operator: not elected for epoch {} (my_group={}, active_group={})",
     epoch_index, my_group, (epoch_index % 3));

That is the static-rotation value from the design the sliding window replaced — the exact shape .claude/rules/batch-operator-schedule-window.md calls out:

"Look for current_batch_op_group = current_epoch_index % batch_op_groups style code — that's the static-rotation anti-pattern this rule replaces."

The branch it narrates compares my_group against epochstate.current_batch_op_group, which the window keeps pinned at 0 (advance pops the expiring group off the front, so the front is always the group on duty). The printed value is not the one the decision used.

The two agree only when epoch_index % 3 == 0. Otherwise the line names a group that was never consulted — and it reads as a flat contradiction when the printed value happens to equal my_group. From a real flow run:

batch_operator: not elected for epoch 1 (my_group=1, active_group=1)
batch_operator: not elected for epoch 4 (my_group=1, active_group=1)

Equal values, yet "not elected". Nothing is wrong with the election — my_group == 1, cur_group == 0, correctly not elected — only with the message. That apparent contradiction is what sent one investigation looking for a bug in the election path rather than in the line describing it.

cur_group is a local in parse_epoch_state, while the log sits in do_poll_epoch_state, which is presumably why the original reached for an expression instead of the value. This retains it as current_group beside my_group — both are per-poll election state, and the existing current_group_members establishes the name — and prints that.

No behavior change. is_elected is computed exactly as before; only the diagnostic changes.

Not included, deliberately

The other item was the pre-mutation pool read in sysio.epoch::advance — slashop / recorddel / termcheck are inline actions that execute only after advance returns, so the pool scan reads operators queued for demotion as still ACTIVE.

It is not carried here, because master already documents that ordering as a deliberate invariant:

"opreg::slash THROWS on an already-SLASHED operator, which would abort advance and stall OPP epoch advancement. These inline slashes execute only after advance returns, so the schedule slide below can temporarily place a just-slashed operator in its new tail while the operator still reads ACTIVE. That member cannot create a later non-canonical observation: sysio.msgch::deliver requires its current sysio.opreg status to be ACTIVE before accepting delivery."

And since #569, sysio.msgch::eligible_batch_operators() intersects the seated group with live opreg ACTIVE status and sizes group_size from the result, so a seated-then-slashed member is excluded and the threshold adapts rather than becoming unreachable.

Changing that ordering means touching an invariant whose own comment warns the alternative aborts advance and stalls OPP advancement chain-wide. That is a design discussion, not a drive-by change — raising it separately.

Validation

Syntax-only compile of the patched translation unit against the existing release build's flags: clean. No contract, ABI, or WASM changes, so the post-contract-refactor rebuild chain does not apply.

[huangminghuang]

One non-blocking consistency comment; the functional diagnostic fix looks sound.

[huangminghuang]

Approved. The existing P3 sentinel comment is non-blocking; the functional diagnostic fix is sound.

[huangminghuang]

[P3] Add regression coverage for the corrected active-group diagnostic This PR fixes a reproduced mismatch, but no test exercises this logging path; the listed validation is syntax-only compilation, and the existing plugin tests do not reach parse_epoch_state / do_poll_epoch_state. Please add a regression case with epoch_index = 1, current_batch_op_group = 0, and this operator in group 1, then assert the message reports active_group=0. Otherwise the old modulo expression could return unnoticed, contrary to the repository’s complete-test-coverage rule.