fix: bump numInstances for delayed grind theorem instances

This PR fixes a bug where delayed E-match theorem instances could
cause uniqueId collisions in the instance tracking map.

The `uniqueId` for theorem instances is generated using `numInstances`,
but this counter was only bumped for immediately activated instances
(`.ready` case), not for delayed instances (`.next` case). This caused
ID collisions:

1. Theorem A matches, becomes delayed, gets uniqueId = N
2. Counter isn't bumped (stays at N)
3. Theorem B matches next, gets uniqueId = N (same!)
4. B's entry overwrites A's entry in instanceMap
5. A's tracking is lost

This manifested as `grind?` and `finish?` producing `instantiate approx`
(meaning "we couldn't determine which theorems to use") instead of
proper `instantiate only [...]` with specific theorem lists.

The fix is to bump `numInstances` for delayed instances too, ensuring
each theorem instance gets a truly unique ID.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>