individuality: a schedules failure fails the whole game read

Description

readCurrentGame batches four storage entries plus the per-player registration read in one Promise.all (packages/individuality/src/game-read.ts:157-163), so a GameSchedules or StoredPhaseDurations failure loses the game and the player registration too. A caller that never reads the schedules cannot opt out. From paritytech/humanity-spa#110, where the card polls with retry: false and blanks for 30 seconds.

The same batch is also reached twice by a consumer that composes: readLiteSignUpRequirement runs runGameRead itself (signup.ts:184), so calling it alongside readCurrentGame costs 14 storage reads for 9 distinct entries.

Why a split and not a flag

#340 answered the previous round of this feedback by adding an option, which is where players came from, so a schedules?: boolean is the likely counter-proposal. Two reasons to split instead. The flag is one bit, since upcoming is derived from durations and cannot be skipped separately. And a flag still leaves both entries inside one Promise.all for the caller who does want them, so it trims the payload without fixing the coupling.

The shape is also not humanity's. The pallet writes the two halves from different origins and forbids changing the phase durations mid-game, and the two independent implementations of this read both split it: dim2-spa (getGame and getGameSchedules) and the iOS host (a separate GameScheduleSyncService). The pallet's own docs ship two examples, game_participation.ts and game_scheduling.ts. readCurrentGame is the only implementation that fuses them, and signup.ts:184 discards the schedules internally.

Not a payload argument: GameSchedules is bounded at 121,849 bytes but measures 649 live on paseo-next-v2. The case is failure isolation.

Deliverable

• readGameStatus, the game and registration only, so a schedules failure cannot reach it.
• The schedules leg split out into its own internal read, not published: nothing wants the schedules on their own today, and removing a published read later would be breaking where adding one is not.
• readCurrentGame unchanged, composed from the two legs under one pinned block.
• registration returned between games instead of read and discarded.
• minor on @parity/product-sdk-individuality and @parity/product-sdk.

How to test

The test.each at game-read.ts:598-607 already pins the current behaviour, so this is a contract change and not a regression. It must stay green for readCurrentGame, with a mirror table for readGameStatus listing only GameIndex, Game and the block pin.

Start in packages/individuality/src/game-read.ts, especially the Promise.all at lines 157-163 and the test.each at 598-607; read signup.ts:184 to understand the composed registration read. Split the status and schedules legs under one pinned block, keep readCurrentGame behavior green, add the readGameStatus mirror table, and apply minor version bumps to both SDK packages.