Fix missing/incorrect @OpaBuiltin annotations for union and object.union

[ML-dev-crypto]

Summary

Both union and object.union are already fully implemented and functionally
correct registered in their respective builtins() maps and dispatched
properly at runtime, so calling either from a Rego policy already works today.
The actual gap is in their @OpaBuiltin metadata annotations, which are used
to generate capabilities.json and docs. This PR fixes that metadata rather
than reimplementing the builtins, so the diff is smaller than the issue's
"missing builtins" framing might suggest.

Issues

#137

Changes

• Added the missing @OpaBuiltin annotation to union (SetBuiltins.java).
  It previously had none, so it was falling back to a minimal
  auto-generated capabilities entry with no description or arg types.
• Replaced object.union's @OpaBuiltin annotation (ObjectBuiltins.java).
  It was copy-pasted from object.keys wrong name, wrong single-arg
  signature, wrong description. This also meant two methods in the same
  file both declared name = "object.keys", an ambiguous collision since
  annotation-scanning order over declared methods isn't guaranteed by the
  JVM. Fixing the name resolves the collision as a side effect.
• Swapped a raw (RegoSet) args[0] cast for the existing getArg helper
  in union, so a bad input type throws a TypeError instead of a raw
  ClassCastException consistent with intersection/and/or in the
  same file.

Testing

• ./gradlew :opa-evaluator:test — full suite passes, including all
  compliance cases under TestData/v1/union/ and TestData/v1/objectunion/.
• ./gradlew checkstyleMain checkstyleTest pmdMain pmdTest — clean, no
  violations in either changed file.
• 11 pre-existing, unrelated failures were present both with and without
  this change (verified via git stash): 9 in FileSystemBundleLoaderTest
  (Windows-specific InvalidPathException, this repo's CI only runs
  ubuntu-latest) and 2 in GoTimeLayoutConverterTest (unrelated to
  bundle/builtin code).

[sspaink]

Metadata-only PR — verified against OPA's capabilities.json / v1/ast/builtins.go and by running this repo's CapabilitiesGenerator on this branch and diffing the emitted JSON for both builtins. The collision fix is correct (object.keys keeps its own annotation on the keys method) and the getArg swap is fine. Two annotation-shape issues remain; both confirmed against the actually-generated capabilities output.

[ML-dev-crypto]

Thanks for the detailed review! Good catch on both points. I've updated the object.union result annotation to use type = "object" with the appropriate dynamic key/value types, and simplified the union argument annotation to @OpaDynamic(type = "set") to match the existing convention.

[sspaink]

Thanks!