feat(matcher/java): add per-request timeout for Maven SHA1 lookups (#1624)

[ChrisJr404]

Description

Closes #1624.

Adds a new external-sources.maven.timeout config field that is wired through to the HTTP client used by the Java matcher's Maven SHA1 upstream search.

external-sources:
  enable: true
  maven:
    search-upstream: true
    timeout: 5s   # new — per-request limit for the SHA1 lookup

The default is 10s, and a value of 0 disables the limit (preserving the previous behavior of http.DefaultClient with no timeout).

Why this fixes the reported pain

The issue describes the scenario where Maven Central (or any configured base-url) is unresponsive: grype falls back to a SHA1 lookup, the request hangs indefinitely, and the user sees a stuck scan with no console signal until they enable --debug. With this change, a per-request timeout fires, the lookup returns an error, and the scan continues with the remaining matchers.

Per-request vs cumulative time

@tgerla suggested in the issue that "total time would be a good starting point" with cascading global + per-source overrides. This PR ships the smallest correct unit first — a per-request timeout — because a single hung request was the actual failure mode in the report. A cumulative time budget can build on top of this once a second external source lands; right now there is only one (Maven), so a global abort-after would be functionally identical to the per-source one.

If the project would prefer a different shape (cumulative-only, or abort-after instead of timeout), happy to revise — small enough patch.

Implementation notes

• New Timeout time.Duration field on the maven struct in cmd/grype/cli/options/datasources.go, default 10s, mapped through ToJavaMatcherConfig() as MavenTimeout.
• New MavenTimeout time.Duration field on java.ExternalSearchConfig.
• NewJavaMatcher constructs a dedicated *http.Client with the configured timeout when it is non-zero, so the timeout does not leak onto unrelated callers of http.DefaultClient. When the timeout is zero, the existing http.DefaultClient is used unchanged.

Tests

Two new sub-tests in TestNewJavaMatcherTimeout:

• timeout aborts hanging upstream — boots an httptest.Server whose handler blocks on a never-closed channel, configures a MavenTimeout of 100ms, and asserts that GetMavenPackageBySha returns an error within ~2s.
• zero timeout disables the per-request limit — asserts the underlying http.Client.Timeout is 0 when no MavenTimeout is configured (so default behavior is preserved).

Test plan

• go build ./... clean
• go test ./grype/matcher/java/ -run TestNewJavaMatcherTimeout passes
• go test ./grype/matcher/java/ ./cmd/grype/cli/options/ — no regressions
• grype --help and YAML config still load with the new field set, default value populated