Validation: add structured author diagnostics and remediation

[zkwentz]

What & Why

A failed gate is only useful if an environment author or agent can act on it. This PR adds typed diagnostics, repository-relative locations, and trusted remediation to both JSON and human reports.

Risk & Review Guidance

• Risk level: MEDIUM — new report fields carry submitted-context evidence
• Task class: feature
• Review focus: src/openenv/validation/models.py:104 for locations/validation; src/openenv/validation/models.py:158 for remediation safety; src/openenv/validation/local.py:534 for human rendering
• Blast radius: Unsafe or vague guidance could leak paths/secrets, execute submitted text, or send authors to the wrong setting.

Decisions & Alternatives

• Remediation is policy-authored and display-only — submitted verifier output cannot create fixes.
• Commands are argv vectors — rejected shell strings to prevent interpretation/injection.
• Locations are repository-relative — portable locally, remotely, and in uploaded reports.

Verification

• PASS: PYTHONPATH=src:envs .venv/bin/python -m pytest tests/ -q -m 'not integration' — 1,559 passed, 114 skipped, 31 external integration tests deselected on the complete stack.
• PASS: Fork whole-stack CI — 7/7 checks passed, including Python 3.11/3.12, lint, docs, lock validation, and package smoke tests.
• NOT verified: Guidance coverage is intentionally strongest for current built-in checks; future adapters must supply their own typed fixes.

Scope & Non-Goals

• The CLI never auto-applies remediation.

Stack

PR 11 of 17; depends on #951.

Full 17-PR stack

1. #942 RFC 008: Spec-neutral local and remote validation architecture
2. #943 Validation foundation: spec-neutral contracts and adapters
3. #944 Validation policy: spec-aware check registry and planner
4. #945 Validation executor: hardened shared reports and eligibility
5. #946 Local validation API: execution-model-aware profiles
6. #947 CLI: validation profiles and shared reports
7. #948 HF runtime: dedicated sandbox execution mode
8. #949 HF certification: enforce trusted dedicated isolation
9. #950 [RFC 008] Define remote author validation and publish gating
10. #951 Validation: unify CLI reports and add a strict publish profile
11. #952 Validation: add structured author diagnostics and remediation ← current
12. #953 Validation: run author validation in dedicated HF Sandboxes
13. #954 Validation: isolate submitted code in author Sandboxes
14. #955 Validation: bind author reports to policy and source
15. #956 CLI: scaffold publish requirements
16. #957 CLI: gate pushes on staged remote validation
17. #958 Docs: explain local, remote, and publish validation

All upstream PRs remain draft while RFC 008 is under review.

[thegovind]

I found two issues in the new remediation contract; the first is a credential-exposure blocker.

1. The URL guard checks parsed.username by truthiness, so https://:secret@example.com/guide is accepted (username == "", password == "secret"). to_dict() redacts it, but the human formatter prints remediation.url directly, so openenv validate emits the credential. I reproduced the full output. Please reject any URL where parsed.username is not None or parsed.password is not None, and render the sanitized value from safe_remediation["url"] rather than the raw field.

2. ValidationRemediation.kind is not yet a reliable typed contract. kind="documentation" without a URL and kind="edit" without a path are both accepted, and fields from unrelated kinds can coexist. The renderer then chooses behavior from whichever field happens to be present instead of from kind, producing non-actionable or misleading guidance. Please enforce kind-specific required/forbidden fields (or model these as a discriminated union): command→argv, documentation→url, edit→path, retry→no destination.

Alignment flag: the first issue violates the no-credential-exposure invariant. Suggested reviewers: @zkwentz and @Darktex.