Hot reload ignores documents referenced only from branch-chain filters

[shaneutt]

Description

FilterPipeline::referenced_files() decides which external documents the config
watcher tracks for hot reload (it is fed into the watch set and composite hash at
server.rs:259).
It walks only top-level filters, not filters nested inside branch chains, so a
document referenced solely from a branch is never watched and editing it does not
trigger a reload.

The method's own doc comment already calls this out
(pipeline/mod.rs:398):

only top-level filters are walked, not filters nested inside branch chains. A
document referenced solely from a branch is therefore not observed.

PipelineFilter carries its resolved branches
(pipeline/filter.rs:44)
and other passes already recurse into branch sub-chains, so the traversal exists;
referenced_files
just iterates self.filters only.

apply_insecure_options
has the identical blind spot (the doc notes widening both belongs in one change):
insecure-option overrides such as csrf_log_only likewise never reach
branch-nested filters.

Steps to reproduce

1. Put a filter that loads an external document (e.g. a policy config_path or a
   guardrails rules file) inside a branch chain rather than the main path.
2. Start the proxy, then edit that referenced document.
3. No reload fires; the old document stays in effect until restart. The same
   filter on the main path would have reloaded.

Expected behavior

referenced_files (and apply_insecure_options) walk branch sub-chains too, so
documents referenced from branch-chain filters are watched and hot-reloaded like
any other filter's.

Praxis version: main (v0.5.3 line)