feat: add extensible state system with category-based command concurrency

[jimsynz]

Summary

• Add custom operational states beyond :idle/:executing via states DSL section
• Add category-based command concurrency with configurable limits
• Add mid-execution state transitions via BB.Command.transition_state/2
• Add reusable BB.Command.SetState handler for simple state changes
• Add compile-time validation of state and category references

New DSL Features

States Section

states do
  initial_state :idle  # default

  state :recording do
    doc "Recording sensor data"
  end

  state :processing do
    doc "Processing recorded data"
  end
end

Categories with Concurrency Limits

commands do
  category :motion do
    concurrency_limit 1  # only one motion command at a time
  end

  category :sensing do
    concurrency_limit 2  # up to 2 concurrent sensing commands
  end

  command :move_to do
    handler MyRobot.Commands.MoveTo
    category :motion
    allowed_states [:idle]
  end
end

BB.Command.SetState Handler

commands do
  command :enter_recording do
    handler {BB.Command.SetState, to: :recording}
    allowed_states [:idle]
  end
end

New Introspection APIs

• BB.Robot.Runtime.operational_state/1 - returns actual state (not :executing)
• BB.Robot.Runtime.executing?/1 - returns true if any command running
• BB.Robot.Runtime.executing?/2 - returns true if specific category occupied
• BB.Robot.Runtime.executing_commands/1 - list of running command info
• BB.Robot.Runtime.category_availability/1 - map of {current, limit} per category

Backwards Compatibility

state/1 returns :executing when in :idle state with commands running, matching previous behaviour. Existing robots without states or category definitions work identically.

Test plan

• All 837 existing tests pass
• 30 new tests for state system features
• All quality checks pass (credo, dialyzer, formatter)