feat(web): expose candidate rule definition dependencies

[Maya-Kid]

Rule chaining and proof traversal already exist, but the rule list does not expose dependencies between rule definitions. Add a candidate-dependency viewer with upstream/downstream rule navigation, including disabled rules and cycles. Navigation clears a filter that would hide the target and focuses its row.

The index matches attribute IDs across conditions and nested computed expressions, and accounts for typing conclusions and ancestor class scopes. It explicitly describes these as potential definition dependencies, not proof that a rule fires, and warns when unfamiliar definitions prevent complete analysis. No inference engine behavior changes.

Rebased onto dev 8d70aebe00e815d1efa017fd1a30534b79be17e6 after #828 and #829 merged. Current head: 0d984fa7f15224745c372cd68f6b396360234d1a.

The three UI conflicts retain both sets of imports, helpers and translations: computed expression display, protected metadata editing and failed-save drafts remain alongside candidate dependency navigation. The dependency index and its tests are byte-for-byte unchanged from the original PR.

Fresh validation on this rebased SHA: Linux frontend 106 tests passed; frozen install, style guard, TypeScript check and production build passed. The backend and migrations have no diff from this dev base. Prior workspace/browser numbers referred to the historical combination branch and are not presented as fresh rebase results.

Refs #477

[WaylandYang]

Merging #829 first, so this one will need a rebase. Confirmed locally against c6029069: #826 through #829 merge onto dev cleanly and this PR then conflicts in exactly the three files you named — web/src/pages/RulesPanel.tsx, web/src/i18n/en.ts and web/src/i18n/zh.ts.

Your description says the union of the two UI PRs was tested locally (957 workspace, 106 frontend), so please rebase onto dev once #829 lands and keep both sets of imports, translation entries and helpers.

On the substance: describing these as candidate definition dependencies rather than proof that a rule fires is the right framing, and it matches the reasoning in 0030 — a rule's inputs are predicates rather than rules, so "does R feed R" can only ever be an approximation. Presenting an approximation as an approximation, and warning when unfamiliar definitions make the analysis incomplete, is what that record asks for.