fix(browser): report non-absolute export paths at their input field - #7097

Summary

When caller-supplied paths to export_web_scripts (capture_path or output_directory) are relative, WebScriptExportService previously emitted a single generic issue with an empty issue path (path: []) and a combined message "capture_path and output_directory must be absolute filesystem paths on this host." even if only one of them was relative. This PR reports non-absolute paths at their respective field (["capture_path"] and/or ["output_directory"]), matching the established boundary issue reporting pattern across REA.

Problem and expected behavior

Previously, passing a relative capture_path or output_directory returned:

{
  "path": [],
  "reason": "invalid_format",
  "message": "capture_path and output_directory must be absolute filesystem paths on this host."
}

Consumers could not determine from the structured issue which argument violated the absolute path requirement. The expected behavior is that each invalid field is reported with its own issue targeting ["capture_path"] or ["output_directory"].

Change and scope

• Updated exportWebScriptsValidated in src/application/WebScriptExportService.ts to inspect capture_path and output_directory individually and return targeted AnalysisInputIssue records for each invalid field.
• Added boundary assertions to tests/boundary/filesystem/webScriptExport.test.ts verifying issue paths and reasons when capture_path is relative, output_directory is relative, or both are relative.

Contribution scope fit: ordinary boundary fix within existing boundaries (not applicable).

Contract and boundary impact

• Semantic owner and earliest changed stage: src/application/WebScriptExportService.ts input validation.
• Contribution scope fit and linked maintainer decision: not applicable.
• CLI and MCP/tool-catalog contract: structured AnalysisInputError now identifies capture_path and/or output_directory in issues[].path.
• Provider, bridge, target-format, or platform compatibility: platform-independent.
• Evidence, artifact, provenance, or reconstruction contract: none.
• Target selection, authority, upstream behavior, and cleanup details (if applicable): none.
• Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Expected effects:

• Read existing files or captured data.
• Launch or attach to a process.
• Inject instrumentation or run scripts/code.
• Change process memory, registers, files, or configuration.
• Contact network services.
• Recover protected code or work around protections.
• Documentation or usability only; no target interaction.
• Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

• Tests added or updated: tests/boundary/filesystem/webScriptExport.test.ts
• Base reproduction or other evidence: previously returned { path: [], reason: "invalid_format" }.
• User-visible CLI/MCP output: structured validation errors cite capture_path or output_directory.
• Remaining proof gaps: none.

For evidence-bearing changes:

• Observed, derived, and inferred claims remain distinguishable.
• Artifact identity, source provenance, and failed attempts remain preserved.
• Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

• npx vitest run tests/boundary/filesystem/webScriptExport.test.ts -t "identifies a missing capture file and rejected host path syntax" — passed (1 passed in 34ms)
• npm run check:fast (turbo run typecheck lint) — passed cleanly (2/2 tasks successful in 1m21s)

Compatibility, safety, and release

• Breaking changes or migration steps: none.
• Real Hopper/Ghidra, browser, or OS coverage: not applicable.
• Package or release metadata impact: none.
• Security, privacy, process, or containment review: none.

Author readiness

Human owner: @saiyam-jain-dev

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• This PR addresses a concrete problem or an agreed enhancement.
• Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
• The PR has one focused outcome and the title follows type(scope): outcome.
• Related issue is linked, or the reason for not linking one is stated above.
• Tests cover changed observable behavior and meaningful failure paths.
• Owning docs, contracts, and generated metadata are updated where needed.
• User-visible CLI/MCP changes include representative output.
• I checked the final diff for secrets, unrelated cleanup, and unsupported claims.