feat(compiler): pathfinding safety limits and mandatory rel_types

What does this MR do and why?

Part of #813 (closed). Three changes to bound pathfinding query fan-out and prevent cluster OOM:

1. Runtime limits: path_finding override in default.yaml with max_execution_time=15s, max_memory_usage=15 GiB, max_rows_to_read=300M. Compiler-side floor enforces these even before config is deployed.

2. Mandatory rel_types: removes the exemption that allowed both-pinned-endpoints pathfinding without rel_types. Even pinned endpoints can hit hub nodes with millions of edges across diverse types.

3. Regression test: asserts all three limits appear in rendered SETTINGS, covering both the None and over-limit clamp paths.

Testing

357 compiler unit tests pass. Includes a regression test for the clamp logic.

Performance Analysis

No impact on correct queries (bounded paths finish sub-second). Pathological fan-out gets a clean ClickHouse error (MEMORY_LIMIT_EXCEEDED / TOO_MANY_ROWS / timeout) instead of consuming 65+ GiB and timing out at 900s.

• This merge request does not introduce any performance regression. If a performance regression is expected, explain why.

Agent context

config/default.yaml: added path_finding block with three limits.

config.rs: PATHFINDING_MAX_* consts, clamp logic in the settings pass (is_none || over ceiling for all three fields). Regression test in lib.rs asserts all three appear in rendered SQL SETTINGS.

validate.rs: removed the both_pinned exemption from the rel_types check.