[TASK] Support cross-file (scan-level) resolution for Go

[n1ckl0sk0rtge]

Background

While auditing the shared call-stack machinery on feat/callstack-ast-detach, we confirmed that Go does not support cross-file resolution, on two independent axes:

1. No hook-based cross-scope resolution. GoDetectionEngine only calls handler.addCallToCallStack(...) — it never calls addHookToHookRepository(...). Only the Java and Python engines register hooks. As a result, a crypto asset reached only through a wrapper function (in the same file or another file) is not resolved for Go. Concretely, given:

   // CrossFileHookWrapper.go
   func HashIt(data []byte) [16]byte { return md5.Sum(data) }
   // CrossFileHookCaller.go
   func RunHash() [16]byte { return HashIt([]byte("data")) }

   the MD5 usage inside HashIt is not surfaced at the HashIt(...) call site.

2. Single-file test harness. GoVerifier (org.sonar.go.testing.GoVerifier) parses exactly one source via SingleFileVerifier (one parse of foo.go). There is no multi-file scan entry point, so even once resolution exists it cannot be verified end-to-end without harness work.

This is a functional gap versus Java (which resolves cross-file via sonar.java.binaries). Python has the same gap on axis 1 but is tracked separately.

Objective

Enable scan-level cross-file resolution for Go so crypto assets reached through wrapper functions across file boundaries are detected and reported in the CBOM, matching Java behaviour.

Proposed approach

• Add hook registration to GoDetectionEngine (mirror JavaDetectionEngine / PythonDetectionEngine: MethodInvocationHookWithParameterResolvement / WithReturnResolvement / EnumHook as applicable) so wrapper-parameter resolution flows through the shared HookRepository + CallStackAgent.
• Verify Go call-record keying: confirm getKeyFormT (record time, via createForHookContext()) aligns with the matcher-lookup key so the shared bucketsToScan narrowing does not silently drop Go detections.
• Extend GoVerifier with a multi-file entry point (e.g. verify(List<String>, check)) that analyzes several sources in one scan sharing the same Handler / call stack.

Testing strategy

• Enable and complete the existing @Disabled guard go/src/test/java/com/ibm/plugin/rules/detection/crossfile/CrossFileHookDetachTest.java (fixtures CrossFileHookCaller.go / CrossFileHookWrapper.go already committed) — it must resolve the wrapped MD5 across the file boundary.
• Add a within-file wrapper-function resolution test for Go (analogue of Python's ResolveValuesWithHooksTest) to cover axis 1 independently of the harness change.

Acceptance criteria

• A Go crypto asset reached only via a wrapper function is detected within a single file.
• The same asset is detected across a file boundary when both files are analyzed in one scan.
• CrossFileHookDetachTest is enabled (no @Disabled) and passes.
• No regression in existing Go detection tests.

References

• Guard test + fixtures added in commit d39f087d (branch feat/callstack-ast-detach).
• Shared machinery: engine/src/main/java/com/ibm/engine/callstack/CallStackAgent.java (onNewHookSubscription, bucketsToScan), engine/src/main/java/com/ibm/engine/language/go/GoDetectionEngine.java.