engine: node eviction & role downgrade now take and converge fleet-wide

[mrjeeves]

Problem

Reported from AllMyStuff (which reads its fleet roles and control-authorization straight from this daemon's signed roster):

• Evicting a node that is/was an owner appeared to do nothing.
• Demoting an owner → manager or → member "didn't take" — the role tag never changed.
• After a node left/was removed, other fleet members still showed it as controllable, and other owners couldn't see it gone — it "remained" in the fleet.

Root cause

Two bugs in the closed-network governance engine (engine/governance.rs), both around how a ratified transition is mirrored into the on-disk roster that everything downstream reads.

1. RoleRevoke was never mirrored locally. try_ratify open-codes a per-variant roster mirror — RoleGrant, Evict, KindChange, TopologyChange — and skipped RoleRevoke entirely. gov.roles dropped the role, but the cached roster authority tag kept rendering the old one, so on the very device that authored the withdrawal the demotion never showed. The gossip-adoption path (mirror_roles_to_roster) already reprojects the whole map, so only the acting device was wrong — which is exactly "I withdrew the role and nothing happened."

2. Evicting a promoted owner/manager resurrected it on gossip-adopting peers. A device admitted as a plain member and later promoted still carries its original member-tier admit in the union-merged member log. A governance-tier evict only extended the owner log, so any peer that re-derived membership from the signed logs — a co-owner adopting via gossip after being offline during the kick — folded that stale admit back in and re-added the evicted device as a plain member: still rostered, still authorised to control the fleet, and invisible-as-gone to every such owner. (An online peer ratifies the evict incrementally via apply_transition and never hits the resurrecting re-projection, which is why this only bit some owners.)

Fix

• Mirror RoleRevoke: reset the target's cached roster tag to member. The device stays in the roster (a withdraw demotes, it doesn't remove) but its authority drops immediately, matching the gossip-adoption path.
• Tombstone evicts in the member log: when a governance-tier evict ratifies, record it in the union-merged member log too, so it supersedes the target's stale member-tier admit. The removal then converges network-wide and survives concurrent authors — the same convergence a plain-member evict already gets.
• Stamp the evict strictly past the target's newest member-log entry (member_tier_timestamp now covers evicts at either tier) so the tombstone wins the last-writer-wins tie instead of the same-second admit it means to remove.

No public API or wire-format change; AllMyStuff picks this up automatically once the bundled daemon is rebuilt (it reads roles/authorization from RosterList).

Tests

• withdrawing_a_role_updates_the_local_roster_tag — asserts the authoring device's roster tag drops to member after a withdraw. Fails without fix Scaffold: pure-Rust mesh workspace ported from MyOwnLLM patterns #1.
• evicting_a_promoted_member_tombstones_its_member_admit — a single-engine projection test that drives the exact functions (verify_log / verify_member_log / member_log_removed) the gossip-adoption path is built on, so it fails deterministically without fix Engine + transport: full mesh stack, end-to-end tested #2 (an online two-engine test passes even unpatched, because online peers ratify incrementally).

Full closed_network_governance + closed_network_roster_guard suites and the 271 myownmesh-core unit tests pass; cargo fmt / clippy clean; daemon crate builds.

🤖 Generated with Claude Code

https://claude.ai/code/session_018x1RV6ppUdMDTHxScVo26L

---

Generated by Claude Code

[mrjeeves]

The check / linux-x86_64 failure on the first run was a pre-existing flake, not a regression from this change: engine::tests::evicted_peer_drop_never_rearms_reconnect asserts its two hardcoded peer ids sort lex-above the engine's own random ephemeral identity. evicted used "z"*60 (always above any 52-char base32 id) but live used "y"*60, which the ~3% of identities starting with z sort above — tripping the precondition assert before the test reaches the drop-peer logic it exercises. My governance change doesn't touch that path.

Reproduced it at 2/60 locally, then made live all-z too (length 61 to stay distinct) so both ids clear every possible identity deterministically — 0/80 after. Pushed as a separate commit (936830d); CI is re-running.

---

Generated by Claude Code