feat(yes-command-api): dispatch aggregate-DSL command groups

[ncri]

Summary

Makes HTTP POST /v1/commands requests targeting an aggregate-DSL command_group route end-to-end the same way regular commands do.

Stacked on top of #28 (the command_group DSL itself). Base branch is feat/command-group-aggregate-dsl; once #28 merges this PR will retarget main automatically.

POST /v1/commands
{
  "commands": [{
    "context": "Companies",
    "subject": "Apprenticeship",
    "command": "CreateApprenticeship",
    "data": { "company_id": "...", "user_id": "...", "name": "Acme", "description": "..." }
  }]
}

End-to-end flow now: Deserializer → BatchAuthorizer (on unwrapped sub-commands) → BatchValidator (same) → command_bus.call (wrapped group intact) → Processor#run_command → aggregate.create_apprenticeship(flat_payload, guards: true) → atomic eventstore commit + read-model updates.

Three small changes (mirroring the legacy stateless Group pattern)

1. Deserializer (yes-command-api/lib/yes/command/api/commands/deserializer.rb)

Adds a command_group_v2_class candidate matching <Context>::<Subject>::CommandGroups::<Name>::Command — the path the command_group DSL macro generates. Tried between V2 and the legacy top-level fallback so existing resolution paths still work.

2. CommandsController#expand_commands

Now unwraps Yes::Core::Commands::CommandGroup in addition to the legacy Group. Each sub-command's existing per-command Authorizer and Validator runs individually via BatchAuthorizer / BatchValidator — no group-level authorizer or validator class needs to exist. The wrapped originals still go to command_bus.call, so the Processor dispatches each group as a single atomic unit.

3. Yes::Core::Commands::Processor#run_command

Passes cmd.payload (flat) when the command is a CommandGroup; keeps cmd.to_h for regular commands. Extracts reinstantiate_with_reserved_keys to handle the commands.map! step that injects origin/batch_id without round-tripping a CommandGroup through its nested to_h form.

4. Supporting fix: CommandGroup#to_h returns flat form

PR #28 had CommandGroup#to_h return the nested per-context/per-subject form (mirroring the legacy Group). That broke round-tripping: Class.new(cmd.to_h) produced a group whose payload was nested — which then dispatched incorrectly. This PR's first commit fixes that so to_h and payload agree on the flat shape. Affects:

• Yes::Core::ActiveJobSerializers::CommandGroupSerializer serialize/deserialize round-trip.
• CommandsController#add_metadata round-trip.

Auth & validate strategy (mirror of legacy)

expand_commands produces the unwrapped list for BatchAuthorizer / BatchValidator; command_bus.call receives the original list with the group wrapped. Each sub-command's existing per-command Authorizer and Validator runs. No group-level authorizer auto-generation needed — the same model the legacy stateless Group already uses.

A future group-level authorize do … end block inside command_group { … } is a deferred follow-up; it would slot on top of this without breaking it.

Commits

1. fix(yes-core): make CommandGroup#to_h round-trip cleanly (flat form).
2. feat(yes-core): dispatch CommandGroup with its flat payload via Processor.
3. feat(yes-command-api): Deserializer + expand_commands + dummy fixtures + request spec + deserializer spec.
4. docs: README note about HTTP invocation.

Test plan

• bundle exec rspec in yes-core — 1163 examples, 0 failures.
• bundle exec rspec in yes-command-api — 185 examples, 0 failures (6 new request-spec cases + 1 new deserializer-spec case + 2 new Processor-spec cases).
• bundle exec rubocop from the umbrella on all touched Ruby files — 0 offenses.
• New request spec asserts the group method is dispatched once on the aggregate with the FLAT payload (not the nested form), and that sub-command authorizers are invoked.

Out of scope (planned follow-ups)

• Group-level authorize do … end DSL inside command_group { … }.
• Group-level validator DSL.
• Top-level app/command_groups/ cross-aggregate form (still goes through the legacy stateless Group path).