fix(api): validate prerequisite parents on feature and experiment writes; block deleting a flag experiments gate on - #6950

A prerequisite may now only point at an existing, unarchived boolean flag
that does not itself depend on the feature being written, matching what the
dashboard's prerequisite picker allows. Previously the API stored a missing,
archived, non-boolean, or cyclic parent and the SDK payload builder then
silently dropped the child flag.

The check runs on per-rule add/patch (v1, v2), bulk create/update (v1, v2,
including the feature-level prerequisites list, which had no existence check
at all), and the revision prerequisites endpoint. Only parents a write
introduces are checked, so a stored reference to a since-archived parent
still posts back unchanged. Cycle detection walks upward from the new
parents one query per hop instead of loading the org's whole feature graph.

The cycle walk now loads ancestors through the org-wide scan context the
delete guard uses, so a parent in a project the caller cannot read still
contributes its edges; the caller's own permissions still decide whether a
direct parent is "not found". A chain still open after fifty hops is refused
instead of silently accepted. The v2 bulk update checked the stored rules
rather than the inbound ones, so rule-level parents there were never
validated. Per-rule handlers share one revision-aware wrapper so the draft's
prerequisites list is the baseline on both sides.

The saved-group reference check no longer reads a rule's prerequisites, so
its input type and the PUT handlers' call sites stop mentioning them. Unit
cases cover what the HTTP harness cannot reach: a cycle closed through an
ancestor the caller cannot read, the depth refusal, and the no-query path
when a write adds no prerequisite.

The delete guard counted only feature prerequisites, so a flag listed in a
running experiment's phase prerequisites could be deleted and the experiment
then evaluated its gate against nothing and vanished from the SDK payload.
Delete and archive now share one experiment-dependents collector, so both
directions see the same dependents.

The guard's REST and dashboard wiring predates this change; what changed is
the service function, so its cases live in a unit test with the loaders
stubbed instead of an HTTP harness.

…service

The prerequisite-parent check moves out of the features API directory into
services/prerequisiteParents so experiments can use it. Experiment phase
prerequisites now get the same existence, archived, and boolean checks on
the REST create/update endpoints and the app API create, phase edit, new
phase, and targeting writes. Experiments are leaves of the prerequisite
graph, so no cycle walk runs for them. As with features, only parents a
write adds are checked.

REST update and both create paths validate the prerequisites of all inbound
phases against everything the stored experiment already references, so an
earlier phase cannot smuggle in a bad parent.

…experiment updates