Make max_distance configurable via RepositoryConfig

[yushan8]

Summary

Adds a server-side default for BFS distance trimming so operators can cap which changed targets are returned without requiring every client to set output_config.max_distance.

What changed

config.RepositoryConfig — new max_distance field (YAML: max_distance). 0 means unset; positive values enable distance trimming at that depth.

config.RepositoryConfigProvider — new interface with a single GetRepositoryConfig(remote string) (RepositoryConfig, bool) method. *config.Config implements it
(verified by a compile-time check). Future implementations (e.g. a remote config service) can be swapped in without touching the controller.

controller — the controller now accepts a RepositoryConfigProvider (optional, safe when nil) instead of *config.Config directly. A new resolveMaxDistance function
merges the two sources with clear priority:

1. Client wins: if output_config.compute_distances is true, use output_config.max_distance (any value, including 0 = direct-only).
2. Server default: if the repo config has max_distance > 0, use it — this enables distance trimming even when the client doesn't request it.
3. Neither set: no distance trimming (-1).

The resolved maxDist is computed once per request and threaded through compareTargetGraphs, compareTargetGraphsAndEdges, sendWithDistanceFilter, and
sendWithDistanceFilterForEdges, which now take int32 maxDist directly instead of *pb.OutputConfig.

Test plan

• Added TestResolveMaxDistance covering all priority cases (client overrides server, server default applied, neither set, max_distance=0 treated as unset in repo
  config)
• All existing controller tests updated and passing (bazel test //...)