mrhid6
5377a1e585
The previous tests reimplemented the target-scope rule instead of calling validateWorkflowTargetScope, so they proved nothing about CreateWorkflow or UpdateWorkflow's actual enforcement. Split the check into a pure decideWorkflowTargetScope (tested directly, no database) and a thin wrapper behind an overridable listServersForScope seam, so tests can invoke the real CreateWorkflow/UpdateWorkflow without a live database and fail if the call sites are removed. Close the time-of-write/time-of-fire gap: a restricted caller could previously save target_tags matching no server today (a selector aimed at hosts not yet provisioned or not yet tagged), pass validation on an empty set, and have the scheduler fire on those hosts the moment they appeared. Now a restricted caller specifying targets that resolve to nothing is refused with the same message as an out-of-scope match; a workflow with no targets at all, and an unrestricted caller, are unaffected. A database error while resolving the fleet now surfaces as an error instead of folding into a pass. Correct three comments that overstated what the code does: the create/update route comment now mentions the tag-scope check, not only validateTargetServers; the schedule route comment explains its safety holds only for workflows written after this check existed, not for rows already in the database under the old rule.