POST /state with "paths": [] returns every changed path instead of none #74

What's wrong

BranchStateHandler (GitBranchStateCache/Endpoints/BranchStateHandler.cs:~223-225) builds the path filter only when the list is non-empty:

HashSet<string>? wanted = request.Paths is { Count: > 0 }
	? new HashSet<string>(request.Paths, StringComparer.Ordinal)
	: null;

wanted = null means "every path", so an empty paths array is treated the same as an omitted one. The README only defines "every path" for omitting the field. The limit check at :~151 uses the same { Count: > 0 } pattern.

Failure scenario

A client builds paths from the set of assets it currently cares about, and that set is empty this heartbeat (for example, nothing is open or checked out):

POST /v1/<up>/<repo>/state {"base":"…","branchPatterns":["origin/main"],"paths":[]}
→ 200 {"paths":{"Content/Chars/Bar.uasset":[…], …}}

The client gets the whole divergence, up to MaxPathsPerRequest (20000) entries with truncated: true, when it asked about nothing. That's wasted bandwidth on every heartbeat for the slow links this service exists to help. It's also a semantic surprise: a client that treats every returned path as "relevant to me" will flag assets it never asked about.

Suggested fix

• Distinguish null from empty: wanted = request.Paths is null ? null : new HashSet<string>(request.Paths, StringComparer.Ordinal). An empty wanted then makes Collect return no paths, while branches, merge bases and status are still reported.
• Alternatively, reject "paths": [] with 400 if an empty query is considered a client error. Either way, document the behaviour in the README.
• Add a StateFlowTests case for paths: [].