CLI: validation profiles and shared reports

[zkwentz]

What & Why

The shared validation API needs a stable author-facing CLI. This PR exposes static, runtime, and full profiles plus JSON/output controls through openenv validate.

Risk & Review Guidance

• Risk level: MEDIUM — changes CLI dispatch and exit behavior
• Task class: feature
• Review focus: src/openenv/cli/commands/validate.py:30 for target/profile resolution and exit codes; tests/test_cli/test_validate.py for URL and report compatibility
• Blast radius: Bad target selection or exit semantics would break local scripts and CI gates.

Decisions & Alternatives

• Explicit profiles — callers can choose fast source checks, runtime checks, or all locally available criteria.
• Retain URL shorthand — preserves existing runtime validation ergonomics.
• JSON is the shared schema — rejected a separate CLI-only report format.

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: No external deployed Space was required for the CLI contract tests.

Scope & Non-Goals

• No strict publish profile or remote Sandbox option in this layer; those are later stack entries.

Stack

PR 6 of 17; depends on #946.

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 ← current
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
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 one blocking semantic issue in this.

--json, --output, or --profile selects the RFC 008 planner, while the unqualified command remains on the legacy validator. That makes a presentation flag change both pass/fail behavior and exit status. I reproduced this with a minimal environment containing an empty uv.lock and no Dockerfile: openenv validate <env> exits 0 with “Ready for multi-mode deployment”, while openenv validate <env> --json exits 1 on the shared source checks. A runtime URL similarly gets a different JSON contract when --json is added even though URL validation is already JSON by default.

This conflicts with RFC 008’s stated contract that all local invocations use the shared planner and differ only in presentation, and it creates exactly the human/agent divergence OpenEnv tries to avoid. I see that #951 later unifies the paths, but #947 should be safe as independently mergeable. Please move that unification into this PR, or reorder/fold the dependency so this PR never lands with split validation semantics.
cc - @zkwentz and @Darktex to minimize human-agent divergence / one canonical workflow