feat: index staking positions, nominations, validators and eras

[prashantasdeveloper]

Summary

Plan 07 — Staking. Turns the staking pallet's raw event log into queryable position state on
top of what Phase 4 (POLYX ledger) already built:

• StakingPosition — current bonded/unbonding/unlocking per stash, reward destination,
  validator/chilled status, and reward/slash totals. bonded/unbonding mirror the same
  staking.ledger chain read AccountBalance.bonded already uses — a second view onto that
  number, never an independently accumulated one that could drift.
• Nomination — one row per identity→validator nomination, diffed against the target set on
  every nominate call (targets no longer nominated close, matching ones stay open, new ones
  open).
• Validator — commission/blocked (ValidatorPrefsSet), permissioning
  (PermissionedIdentityAdded/Removed), and active-set membership (StakersElected).
• Era — opened by StakersElected (which resolves the era index and elected validator set
  from chain storage, since the event itself carries neither) and closed by EraPaid
  (payout/remainder/total staked).
• StakingEvent gains eraIndex/position, reusing the same PayoutStarted-fed cache
  PolyxEntry.eraIndex already relies on.

Also retires two defects in the existing mapStakingEvent.ts log path along the way: B1
(extract8xStakingAmount, a value-shape guessing heuristic) and B3 (an unhandled v8 staking
event silently dropped amount with no record — now an IndexerAnomaly).

Staking Fixes

• handleNominated never persisted the StakingPosition it created — a dangling relation on any
  stash's first nomination.
• A failed session.validators()/era-set read at StakersElected collapsed to "nobody elected,"
  deactivating every validator on a transient RPC error instead of leaving the prior set alone.
• Era resolution was reading the wrong storage. Verified against pallet-staking's actual
  try_trigger_new_era source: StakersElected fires before ActiveEra/session.validators()
  update, so both were still reporting the outgoing era/set at that moment. Switched to
  staking.currentEra() (bumped in the same block) and staking.erasStakers(eraIndex) keys (the
  newly-elected set, populated in that same block).
• project.ts ran handleStakingEvent before the handler that creates StakingPosition for
  Bonded/Nominated — so StakingEvent.position was null on a stash's very first bond or
  nomination. Reordered.
• get8xStakingEventDetails read .stash unconditionally before its switch, which would throw
  (crash the handler) instead of recording the anomaly it advertises, for any future event without
  a stash field.
• Chilled/Kicked had no pre-v8 decode shape — verified against Polymesh's actual v7.4.0 source
  (Chilled{stash}, Kicked{nominator,stash}); missing shapes meant a crash on the first pre-v8
  occurrence during a full resync.
• Non-null Account relations (StakingPosition.stash/.controller, Validator.account,
  Nomination.validator) were written from raw addresses with no guarantee the Account row
  existed — fixed via ledgerAccount.
• Minor: a stale JSDoc comment left behind by extract8xStakingAmount's deletion; isChilled
  never cleared on re-nomination/re-validation; a ledger-read-fallback delta that could go
  negative; a Nomination id collision risk within a batched block.

Consumer impact

Purely additive. StakingEvent is unchanged apart from two new nullable fields; the portal's
stakingEvents query (eventId: {in: [Reward, Rewarded]}) is untouched. New capability: current
bonded/unbonding/nominations per account, validator status, and per-era reward aggregation via
groupedAggregates(groupBy: [ERA_INDEX]) on StakingEvent — none expressible before.

Test plan

• yarn codegen
• yarn typecheck
• yarn lint
• yarn build
• yarn test:unit (602 tests, 57 suites)
• 10-index-per-entity cap checked on every new/changed entity

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud