subgraph: matchstick suite never observes nextMetaId or any multi-event path

[thedavidmeister]

Adversarial read at bba50a7. The subgraph mappings cannot be mutation-probed in this repo's dev shell (no docker/matchstick locally), so this is the read-derived equivalent of surviving mutants in subgraph/tests/metaBoard.test.ts. Filed for triage; no adjudication here.

The matchstick suite processes at most one handleMetaV1_2 event per store state and never asserts the value of MetaBoard.nextMetaId. Consequences, stated as mutants the current suite would not kill in subgraph/src/metaBoard.ts:

1. metaBoard.nextMetaId = metaBoard.nextMetaId.plus(BigInt.fromI32(1)) — deleting this line, changing the increment to any other value, or deleting the final metaBoard.save() leaves every existing assertion green. No test loads the board after the handler and checks nextMetaId, and no test runs a second event to observe id "1".

2. new MetaV1(metaBoard.nextMetaId.toString()) — hardcoding the id to "0" survives: the only id ever asserted is "0" (MetaV1Entity.load("0")), and assert.entityCount(ENTITY_TYPE_META_V1, 1) is only ever checked after a single event, so the everything-overwrites-entity-zero failure mode is invisible.

3. The multi-event batch helper handleNewMetaV1Events exists in subgraph/tests/utils.ts but no test calls it — the counter-increment behaviour it would naturally exercise is unexercised.

4. The multi-board path (MetaBoard.load(event.address) distinguishing two source addresses) is never exercised: no test emits events from two different event.address values, so the board-scoping of the counter and the id collision described in subgraph: MetaV1 id is the bare per-board counter — collision across datasources, lexicographic ordering, relation keyed off address field #227 are both outside the suite's observation.

For triage: whether the matchstick suite should gain a two-event (and ideally two-board) scenario asserting nextMetaId, the second MetaV1 id, and entity counts.