fix(suppress): don't over-decline a nearer descendant's own route/trigger

A group's template suppression is "coarse by reference" (path for routes,
handler-name for triggers), and both resolution points dropped ANY inherited
row matching that reference across the whole subtree — including one a NEARER
descendant group deliberately re-declared. So an ancestor group G that declines
a far-ancestor's `/x` (or `audit` handler) would also silently kill a child
group H's OWN `/x` / `audit`-bound trigger at the same reference, violating the
documented "an owner can only decline what it inherits, never a descendant's
own rows" invariant.

Fix: gate each decline on the chain DEPTH of the suppressor vs the target's
owner — a suppressor at depth `d_s` may only decline a row whose owner is
strictly ABOVE it (`target_depth > d_s`):
- Routes: `list_route_suppressions` now returns `(app, path, suppressor_depth)`;
  the rebuild folds it to the min depth per `(app, path)` and
  `compile_effective_routes` skips an inherited route only when
  `route.depth > suppressor_depth`. (This also subsumes the old `depth > 0`
  inherited-only gate.)
- Triggers: the dispatch anti-join gains `AND sc.depth < c.depth` (the
  suppressor's chain depth below the trigger owner's), correlating on the outer
  `chain c` that every kv/docs/files/pubsub match query already binds.

An app's own suppression is depth 0 → still declines anything it inherits; a
group's suppression declines only what that group itself inherits. `sealed`
still overrides. No schema change.

Pinned by a new `compile_effective_routes` unit test (a depth-1 descendant
route survives a depth-2 suppression that declines a depth-3 template) and a
new `group_suppression` DB test (same for triggers); all existing suppression /
sealed / template journeys stay green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/tests/sealed_templates.rs

@@ -15,8 +15,6 @@
     clippy::too_many_lines
 )]
 
-use std::collections::HashSet;
-
 use picloud_manager_core::route_admin::compile_effective_routes;
 use picloud_manager_core::route_repo::{PostgresRouteRepository, RouteRepository};
 use picloud_manager_core::trigger_repo::{PostgresTriggerRepo, TriggerRepo};
@@ -111,12 +109,18 @@ async fn route_template(pool: &PgPool, group: Uuid, script: Uuid, path: &str, se
 /// Whether `app`'s compiled route slice serves `path`.
 async fn serves(repo: &PostgresRouteRepository, app: Uuid, path: &str) -> bool {
     let effective = repo.list_effective().await.expect("list_effective");
-    let suppressed: HashSet<(AppId, String)> = repo
+    let mut suppressed: std::collections::HashMap<(AppId, String), i32> =
+        std::collections::HashMap::new();
+    for (a, p, d) in repo
         .list_route_suppressions()
         .await
         .expect("list_route_suppressions")
-        .into_iter()
-        .collect();
+    {
+        suppressed
+            .entry((a, p))
+            .and_modify(|x| *x = (*x).min(d))
+            .or_insert(d);
+    }
     compile_effective_routes(&effective, &suppressed)
         .into_iter()
         .any(|c| c.app_id == AppId::from(app) && format!("{:?}", c.path).contains(path))