manifest/bazel: nested-workspace + Bazel-native Maven extraction (#1342)

## Summary

Rewrites `socket manifest bazel`'s Maven extraction pipeline so it (a)
discovers every workspace under the scan root, not just `cwd`, and (b)
relies on Bazel-native commands for repo enumeration instead of static
Starlark regex parsing.

The former version was a bit over engineered, it was doing the following things wrong:
- Parsing StarLark files to find maven repos, turns out there was a programmatic way of doing it. 
- Repeating server side work by parsing `maven_install.json`. 
- Not handling nested bazel modules correctluy.

After some more iteration I have landed on a better flow that also more easlily extends to other languages: 

```
1. Walk the scan root for every workspace (MODULE.bazel / WORKSPACE /
   WORKSPACE.bazel). Caller-supplied prune policy.
2. Per workspace, discover Maven hubs:
   - Bzlmod: bazel mod show_extension @rules_jvm_external//:extensions.bzl%maven
   - WORKSPACE: probe conventional names (@maven, @maven_install,
     @maven_dev, @unpinned_maven, @maven_unpinned). Tri-state
     classifier (populated / empty / not-defined).
3. Per populated candidate, run per-repo metadata cquery:
     attr("tags", "\bmaven_coordinates=", @<repo>//...)
     ∪ attr("maven_coordinates", ".+", @<repo>//...)
     ∪ attr("maven_url", ".+", @<repo>//...)
   --output=jsonproto --keep_going
4. Aggregate across all workspaces; dedup by full Maven coordinate.
5. Write synthesized maven_install.json.
```

Author: simonhj