Validate control-task joint counts in the params model, not in __init__

From Tom's review on #4096: https://github.com/dimensionalOS/dimos/pull/4096#discussion_r3997153809

BaseTrajectoryTask.__init__ checks len(joint_names) != 3 by hand, and the same check sits in __init__ on HolonomicPoseFollowerTask and PathFollowerTask. Moving it into the pydantic params model names the field in the error, reports every bad field at once, fails at config-parse time before any worker starts or hardware connects, and puts the constraint into the schema that dimos run <blueprint> --help prints.

Two things make it more than a one-line move, which is why it is not in #4096. joint_names lives on TaskConfig rather than in params, so create_task has to merge it in (model_validate({**cfg.params, "joint_names": cfg.joint_names})) or blueprints end up declaring joints twice. And the __init__ check is the only thing guarding direct construction of the dataclass config, which the tests use, so removing it needs a call on whether that path stays validated.

Worth doing across the three followers together rather than in one of them.

Trace BaseTrajectoryTask, HolonomicPoseFollowerTask, PathFollowerTask, TaskConfig, and create_task to understand how joint_names reaches each params model. Check the tests that directly construct the dataclass config before changing validation, then verify all three followers report invalid counts during config parsing and that dimos run --help exposes the constraint without duplicate joint declarations.