refactor: expressive commit points in GameLoop

[ThorstenSuckow]

Summary

The current addCommitPoint() API in the GameLoop uses opaque, coarse-grained enum values (e.g. CommitPoint::Structural, CommitPoint::FlushCommands) that do not convey which commands are flushed or which managers are invoked. This makes the phase/pass configuration harder to reason about and limits fine-grained control over execution order within a single commit point.

Problem

1. Lack of specificity – addCommitPoint(CommitPoint::FlushCommands) flushes all pending commands indiscriminately. There is no way to express that only a subset of command types (e.g. WindowCreateCommand) should be flushed at a particular point.

2. No per-manager granularity – FlushManagers processes every registered manager. In practice, some passes need only a single manager to run (e.g. PlatformManager after window creation).

3. Ordering within a commit point – Certain managers may enqueue new commands during their flush() that must be processed by other managers within the same commit point. The current design does not support specifying an intra-commit execution order of flush → enqueue → flush chains.

Proposed API

Allow addCommitPoint to accept a variadic list of typed flush directives:

gameLoop.phase(PhaseType::Pre)
    .addPass<GameState>(GameState::Booting)
    .addSystem<PlatformInitSystem>()
    .addCommitPoint(
        FlushCommands,                       // flush all pending commands
        FlushManagers                        // then flush all managers
    )

    .addPass<GameState>(GameState::Live | GameState::Booted)
    .addSystem<WindowCreateSystem>()
    .addCommitPoint(
        FlushCommands<WindowCreateCommand>,  // flush only WindowCreateCommand
        FlushManager<PlatformManager>        // then flush only PlatformManager
    );

Key design points

• FlushCommands (unparameterised) – flush the entire command buffer (current behaviour).
• FlushCommands<Cmd...> – flush only the queues for the specified command type(s) from the TypedCommandBuffer.
• FlushManagers (unparameterised) – flush all registered managers (current behaviour).
• FlushManager<M> – flush only the specified manager.
• Directives are executed in declaration order, so a manager that enqueues new commands can be followed by another FlushCommands or FlushManager within the same commit point.

Intra-commit chaining

Some managers produce commands during flush() that should be consumed by other managers in the same commit point. The ordered directive list makes this expressible:

.addCommitPoint(
    FlushCommands,
    FlushManager<SpawnManager>,          // may enqueue PoolAlloc commands
    FlushCommands<PoolAllocCommand>,     // drain those commands
    FlushManager<GameObjectPoolManager>  // process the allocations
)

Acceptance criteria

• addCommitPoint accepts a variadic set of typed flush directives.
• Unparameterised FlushCommands / FlushManagers retain current behaviour.
• Typed variants flush only the specified command queue / manager.
• Directives within a single commit point execute in declaration order.
• Existing examples and tests compile and pass without changes (backward-compatible overload or migration).
• Documentation in docs/core-concepts/ and API docs updated accordingly.