fix(supernode): preserve audit identities across account migration (companion to chain #199)

[mateeullahmalik]

Preserve audit identities across account migration (SuperNode companion to chain PR2)

Companion to LumeraProtocol/lumera PR #199 (matee/evmigration-continuity-core).
Requires the chain protos from that PR — EpochReport.current_submitter, QueryAssignedTargetsResponse.reporter_supernode_account, target_account_mappings. Cannot compile against released chain tags. Do not merge before the chain PR.

Why

After an account migration, a SuperNode has two distinct identities that the daemon currently conflates:

• A — epoch-logical account: the identity frozen in the epoch anchor's active/target set at anchor time. Reports are keyed and scored under this.
• B — signer / current account: the account registered and holding keys today. This is what actually signs submissions.

Likewise for targets: T_A is the logical target identity recorded in the epoch, while T_B is the live account whose transport address you must actually dial.

Before this change the daemon used one account for both roles. After a migration that is wrong in both directions: it either signs with an identity the chain no longer recognises, or reports under an identity nobody scores — and it tries to reach peers at addresses belonging to retired accounts.

What changes

Splits the two axes across the assignment and dispatch paths:

• pkg/lumera/modules/audit/assignment.go — consumes the new chain query contract, surfacing the logical reporter and the ordered logical→current target mappings while preserving target order.
• supernode/host_reporter/service.go — reports under the epoch-logical identity A, signs as current account B.
• supernode/storage_challenge/lep6_dispatch.go — scores against logical target T_A, dispatches to live transport target T_B.
• supernode/storage_challenge/lep6_client_factory.go — resolves the live account for connection setup.
• supernode/storage_challenge/lep6_recheck.go — resolves rechecks against historical transcript identity, avoiding the recheck deadlock where a transcript requires the old target but current-registration checks require the new one.

Target ordering is preserved throughout: target_account_mappings is index-aligned with target_supernode_accounts, so existing order-sensitive logic is unaffected.

Compatibility and rollout order

• Backward compatible with unmigrated nodes. With no account transition, A == B and T_A == T_B, so behavior is identical to today.
• Empty current_submitter on historical reports decodes correctly — reports written before the chain change remain readable.
• Rollout order is mandatory: chain PR2 merges and deploys with migration disabled → SuperNodes upgrade to this release → only then does governance move disabled → canary. SuperNodes must be compatible before any migration can execute.

Risks

Limited to the audit/LEP-6 reporting and storage-challenge paths. A wrong split does not corrupt chain state — the chain validates identities independently — but it can cause a migrated node to fail submission or miss peer observations for an epoch. Mitigated by the A==B degenerate case being the common path and covered by tests.

Rollback

Revert and redeploy the prior SuperNode release. Safe as long as no account migration has executed on the target network; the chain keeps migration disabled by default precisely so this ordering holds.

Evidence

Verified against chain PR #199 head d7504279 using a throwaway Go workspace joining both repos (never committed; one go work edit -replace needed for the go-ethereum replacement-directive conflict between the two modules):

go build ./...                              BUILD OK
go test ./pkg/lumera/modules/audit/...      PASS
go test ./supernode/host_reporter/...       PASS
go test ./supernode/storage_challenge/...   PASS

Not yet done

• Multi-SuperNode devnet functional gate against the exact chain release artifact (not a local patch)
• Shared signed-transcript vectors consumed by both chain and SuperNode tests
• Release artifact checksum + minimum-version statement for operators

[mateeullahmalik]

CI status — expected red until chain #199 merges

All failing jobs (build, unit-tests, integration-tests, lep6-e2e-tests, cascade-e2e-tests) fail for one verified reason: this branch consumes proto fields that exist only in chain PR #199 and are absent from the pinned released tag v1.20.0-rc3.

Exact compiler output from the unit-tests job:

pkg/lumera/modules/audit/assignment.go:37:37: resp.ReporterSupernodeAccount undefined
  (type *lumera/x/audit/v1/types.QueryAssignedTargetsResponse has no field or method ReporterSupernodeAccount)
pkg/lumera/modules/audit/assignment.go:41:14: resp.TargetAccountMappings undefined
pkg/lumera/modules/audit/assignment.go:42:124: resp.TargetAccountMappings undefined
pkg/lumera/modules/audit/assignment.go:54:37: resp.TargetAccountMappings undefined
pkg/lumera/modules/audit/assignment.go:55:37: resp.TargetAccountMappings undefined

I checked the full job log for any other error class — there is none. CodeQL, Analyze (go), Analyze (actions) and sn-manager-tests all pass.

Verified green against the actual chain PR head

Using a throwaway Go workspace joining this branch with LumeraProtocol/lumera@d7504279 (never committed; one go work edit -replace was needed to resolve the go-ethereum replacement-directive conflict between the two modules):

go build ./...                              BUILD OK
go test ./pkg/lumera/modules/audit/...      ok
go test ./supernode/host_reporter/...       ok
go test ./supernode/storage_challenge/...   ok

Unblocking

CI here goes green once chain #199 merges and this branch's go.mod is bumped to a chain version containing the new protos. Holding this PR in draft until then — per the rollout order in the description, SuperNodes must be compatible before governance moves migration from disabled to canary.