Fix GitLab report links, identifiers and locations, and make diff baselines resilient - #337

The workspace-scoped head scan lookup treated any failed request as "no
baseline". The SDK logs and returns {} for every non-200, so a transient API
error resolved to None, and create_new_diff answers None by creating an empty
baseline scan -- reporting every dependency in the repository as newly added.
An absent "results" key now raises APIFailure, and resolve_base_full_scan_id
surfaces it the same way a missing --base-commit-sha baseline is surfaced.

Selecting the newest scan on the default branch also reintroduced temporary
scans, which the repository head pointer had excluded. The empty baseline scan
that create_new_diff creates inherits the branch and commit of the run that
created it, so a default-branch run whose real scan fails leaves that empty scan
as the newest one. Both baseline lookups now skip tmp scans.

Also unwrap scan_type before it is URL encoded. FullScanParams types it as a
ScanType enum, and urlencode renders a (str, Enum) member as its repr-style
name, which would filter on a scan type that does not exist.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

Socket addresses Maven package pages as groupId:artifactId. The CLI emitted the
slash-separated form, so every Maven package link 404'd -- the dashboard's Maven
handler rejects the slash form outright with "Maven package must have a colon".
Removing the enum leak from these URLs fixed how they looked without fixing where
they pointed.

The separator now follows the ecosystem, via Package.socket_url, which both the
full-scan and diff construction paths call. Previously each built its URL inline
and they disagreed on namespace handling, so the same package could produce
different links depending on which path ran.

Purl strings are deliberately left on the slash form for every ecosystem: that is
what the purl spec defines and what Socket's purl API consumes. Only the
dashboard URL is ecosystem-dependent.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

The Maven separator rule was explained in three places and the enum-unwrapping
rule in two. Each now has one home: the separator at URL_NAMESPACE_SEPARATORS
where it is defined, the enum behavior at each helper that depends on it, stated
once rather than narrated.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

An ecosystem with its own URL separator cannot be addressed without both halves
of the coordinate. A Maven artifact that arrives with no groupId still gets a
link so the finding reports, but that link cannot resolve, and previously it was
emitted silently. It now logs a warning naming the package.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…ations

Two defects in the same location block.

The manifest path fell back to "unknown" whenever a package had no introducing
chain. That happens routinely for a transitive package whose top-level ancestors
are absent from the scan's package set, which a diff-scoped run causes by
construction. The package records its own manifest files regardless, so those
are now used before giving up.

Directness was inferred by looking for " > " in the introducing entry, but no
producer emits that separator -- get_source_data yields either ("direct", files)
or (ancestor_purl, files). Every finding was therefore reported as direct,
including transitive ones. It now comes from the package record.

The dependency chain was also parsed into a local that was never read, and the
docstring advertised a dependency_path key the function never returned. Both are
removed rather than wired up, since the GitLab schema expects dependency
references rather than a name path.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

The GitLab dependency-scanning schema types an identifier's url as a string
matching ^(https?|ftp)://, so a null fails validation. The socket_alert
identifier emitted null whenever an alert carried no url, which invalidates that
finding for every consumer that validates the report.

Verified against the published schema: a report containing an alert with no url
now produces zero validation errors.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…mmit-sha

A merge base can have no full scan even when default-branch scanning is
configured and running: squash merges and rebases rewrite commits, and a
multi-commit push produces one scan for the tip while leaving the commits in
between unscanned. Any of those turned every open merge request into a failed
pipeline, because a missing baseline was a hard stop with no degraded mode.

The requested commit is still preferred. When it has no scan, one listing of
recent scans is matched against local first-parent history and the nearest
scanned ancestor is used instead, logged at warning with the commit chosen and
its distance. Only an unreachable ancestor now fails the run.

Both bounds are fixed and neither costs an extra request: the listing is fetched
once, and the walk stops at a set depth. Following first parents keeps a merge
commit from contributing everything merged into it, and a shallow checkout
simply narrows the search rather than breaking it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>