fix(security): the shipping build has no SSRF guard on scan targets

[0xmanhnv]

The gap

In the default build — what ships, and what demo-agent runs — a scan
command is handled by core.NewDefaultCommandExecutor from sdk-go:

// sdk-go v0.5.2, pkg/core/command_poller.go:491
scanResult, err := scanner.Scan(ctx, payload.Target, opts)

No validation. And the pinned version has nothing to validate with:

$ ls $GOPATH/pkg/mod/github.com/openctemio/sdk-go@v0.5.2/pkg/
adapters audit chunk client compress connectors core credentials ctis
enrichers errors gitenv handler health metrics mocks options pipeline
platform providers resource retry scanners shared strategy transport
                              ^ no httpsec

$ grep -rc "169.254\|httpsec\|IsPrivate" .../sdk-go@v0.5.2/pkg/
(nothing)

The hardening is on sdk-go main (pkg/httpsec exists there). It is not in
the version agent/go.mod pins.

The agent's own guard does exist and is compiled into every build —
validateScanTarget in vulnscan.go, plus dangerousToolFlags — but it is
reachable only through executor.Router, and:

$ /usr/bin/grep -rn "NewRouter(" --include="*.go" .
./platform.go:171:  router := executor.NewRouter(...)   # //go:build platform

So it is compiled into every build and reachable from none of the shipping ones.

Net: the narrow validate path has been guarded since it landed; scan —
which is what actually runs, with targets drawn from assets.name, i.e. from
ingest — has not been.

The fix

Guard at the wrapper that already intercepts validate
(ValidatingCommandExecutor), reusing the same validateScannerTargets the
validate path uses. Both the single target and the targets array the API
writes are checked.

Why here rather than bumping sdk-go. A dependency bump fixes today and
leaves the next downgrade — or a fresh module graph resolution — to silently
reopen it. Guarding at the boundary the agent owns means the answer no longer
depends on which sdk-go is pinned. The bump is still worth doing; it is not what
makes this safe.

Fails closed, including on a payload it cannot parse: the whole reason the
guard exists is that what reaches the scanner is influenced by ingested data, so
forwarding an unread payload would defeat it.

One consequence operators must know

The guard resolves hostnames and refuses what it cannot resolve. An
internal-only DNS name that used to scan will be refused unless it resolves for
the agent.

That is pre-existing validateScannerTarget behaviour — the platform build has
always worked this way — but extending the guard's reach extends this with it.
It is pinned by TestScanGuard_RefusesUnresolvableHost rather than left to be
found by whoever's scans stop. RFC1918 targets remain available via
AGENT_ALLOW_PRIVATE_TARGETS; the hard-blocked tier is not openable.

Verified

Check	Result
5 guard tests	pass
the blocking tests against current main	all 5 hard-blocked targets reach the SDK executor
go build ./... and go build -tags platform ./...	exit 0
go vet ./...	exit 0
go test ./...	pass

The failure message on main is the finding stated plainly:

the scan command reached the SDK executor — sdk-go v0.5.2 passes
payload.Target straight to scanner.Scan with no validation

TestScanGuard_AllowsOrdinaryTargets matters as much as the blocking one — a
guard that refuses real scans gets reverted, which leaves you worse off than
before. It uses IP literals so it does not depend on DNS in CI.

Follow-ups, not in this PR

• Bump sdk-go past v0.5.2 once a tag carrying pkg/httpsec exists — defence
  in depth, and it fixes the platform build's transitive use too. Today the
  newest tag is v0.5.2 and the hardening is only on main.
• The API performs no target validation at all on scan or validate commands
  (SecurityValidator.ValidateCommandPayload has one production caller, the
  pipeline path). The agent should not be the only enforcement point for an
  attacker-influenceable address.