pfSense

Limiters with per-schedule bandwidth only take effect at filter reload.

The 15 minute cron (`0,15,30,45 * * * * /etc/rc.filter_configure_sync`) that makes them switch is only installed when `$time_based_rules` is true. Since the fix for #11636 (commit 246a8832), filter.inc sets that flag for limiter schedules by matching the rule's dnpipe against top-level dnshaper/queue names:

```
foreach (config_get_path('dnshaper/queue', []) as $queue) {
if (($queue['name'] == $rule['dnpipe']) && is_array($queue['bandwidth']['item'])) { ...
```

The loop only walks parent limiters. If the rule points at a child queue (the documented fq_codel setup: floating match/pass rule with In/Out pipe = child queues), the name never matches, the flag stays false, no cron is installed, and the pipe stays on whichever schedule was active at the last manual reload.

Reproduce (Plus 26.07, also present on master):

1. Create limiters WANDown/WANUp with fq_codel and a child queue each (WANDownQ/WANUpQ).
2. On each parent limiter, add two bandwidth rows with different schedules.
3. Floating pass rule on WAN out, In/Out pipe = WANUpQ / WANDownQ. Apply.
4. Check /etc/crontab: no rc.filter_configure_sync entry. dnctl pipe show never changes across the schedule boundary.
5. Change the rule to reference the parent limiters instead: cron is installed.

Expected: the check should also resolve child queues (dnshaper/queue/N/queue/M) to their parent pipe, or walk `$dummynet_name_list`, so a schedule on the parent triggers the cron.

Workaround: add the cron manually, or reference the parent limiters in the rule.