feat: add URL detection and integrity hash parsing to harness package

[ggallen]

Summary

• Add IsURL, IsAbsPath, IsRelPath helpers for classifying resource references
• Add ParseIntegrityHash for extracting and validating #sha256=... fragments from URLs
• Foundation for ADR-0038 universal harness access — no callers yet

Test plan

• Unit tests for all functions with edge cases (userinfo, path traversal, hex validation)
• go test ./internal/harness/... passes
• make lint passes

🤖 Generated with Claude Code

[github-actions]

Site preview

Preview: https://9c414d60-site.fullsend-ai.workers.dev

Commit: 242828836d38af12d9a0d9c637023baacb096981

[fullsend-ai-review]

Review

Findings

No findings.

Previous run

Review

Findings

No findings.

Clean utility addition — URL validation has appropriate defense-in-depth (HTTPS-only, userinfo rejection, belt-and-suspenders @ check), ParseIntegrityHash correctly validates hash format and rejects path traversal, and the test suite covers edge cases well. Plan doc updated to match implementation.

Previous run (2)

Review

Findings

No findings.

Previous run (3)

Review

Findings

Low

• [correctness] internal/harness/url.go:43 — ParseIntegrityHash godoc does not mention that uppercase hex characters (A-F) are rejected. SHA-256 hashes are commonly rendered with mixed case, so callers may be surprised when a valid-looking hash like ABCDEF01... returns hasHash=false. Consider documenting the lowercase-only requirement in the godoc, or accepting uppercase with strings.ToLower normalization.

Info

• [correctness] internal/harness/url.go:39 — IsRelPath("") returns true for an empty string. This is tested and intentional, but empty string is not a meaningful file path. Future callers that pass user input through IsRelPath without an empty-string guard may misclassify missing values as relative paths.

[fullsend-ai-review]

Review follow-ups

Created follow-up issues for actionable non-blocking review findings:

• #1099 — ParseIntegrityHash godoc does not mention that uppercase hex characters (A-F) are rejected. SHA-256 hashes are commonly rendered with mixed case, so callers may be surprised when a valid-looking hash returns hasHash=false.