feat(checker): add OrderedStepChecker + CheckerManager wiring

[keyneszeng]

Summary

Adds a stateful checker that runs its sub-checkers in sequence (step 1 must be satisfied before step 2 is evaluated). Mirrors Hub OrderedStepChecker production usage — the primitive behind multi-phase LIBERO tasks.

Why the CheckerManager change is required

OrderedStepChecker is a composite-style checker (it owns sub-checkers), and we need a way to instantiate its sub-checkers without introducing an ESM circular import (checker -> index -> checker). Two design points:

1. OrderedStepChecker accepts either options.steps (raw config) plus an injected options.registry, or options.checkers (pre-built instances).
2. CheckerManager.createChecker is taught to handle OrderedStepChecker explicitly: it recursively resolves each sub-config via this.createChecker (same pattern as CompositeChecker) and passes the pre-built instances in. This is the path production tasks will use.

I verified this end-to-end with mock data: CheckerManager correctly instantiates the OrderedStepChecker + 2 sub-checkers (BodyContact + PositionDelta), and the ordered step logic returns true only when all sub-checkers pass in order.

Cross-repo coordination

• Python (companion PR): stateless per-call function; walks a whole trajectory with a cursor.
• JS (this PR): stateful across check() calls.
• Hub backend: already uses the same ordered-step semantics.

Task config schema (matches Hub)

{
  "type": "OrderedStepChecker",
  "steps": [
    {"type": "RelativePositionBoundsChecker", ...},
    {"type": "GripperOpenChecker", ...}
  ],
  "allow_reentry": false
}

Checklist

• CheckerManager change mirrors CompositeChecker handling
• reset() resets currentStep and recursively resets sub-checkers
• getStatus() / getProgress() per-step