fix: version workspace status JSON contract

[codeforester]

Summary

• Add schema_version: 1 to basectl workspace status --format json.
• Publish and enforce the workspace status schema for empty, manifest-backed, and discovery-backed workspaces.
• Register the contract in stability, command-reference, contract registry, and contract runner documentation.

Validation

• git diff --check
• Focused workspace/status and documentation tests: 90 passed, 4 subtests passed.
• Contract slice: passed.
• Full bin/base-test gate: 1,783 Python tests and 1,035 BATS checks passed.

Closes #2467

[codeforester]

Reviewed current head ee893bf against issue #2467. No blocking findings: the status envelope now emits schema_version: 1, the published schema covers empty/manifest/discovery-backed payloads, the contract runner includes the new schema test, and the documentation/registry links are consistent. Focused validation passed: 104 tests plus 4 subtests.

[codeforester]

Re-reviewed head ee893bf against #2467. This time I checked the schema against what the serializer actually emits, not just the files in the diff.

Verdict: no blocking findings. All four acceptance criteria are met.

What I verified:

• Schema matches real output. I ran basectl workspace status --format json (via python -m base_projects) in scenarios the new test doesn't cover, and every payload validates against docs/schemas/workspace-status.json. The scenarios: a manifest-backed workspace with a valid project, a non-Base repo (manifest: missing, manifest_path: null), an invalid manifest, a missing required repo (error, exit 1), a missing optional repo (warn), and url/default_branch metadata. Also a discovery-backed workspace containing an invalid manifest, and a uv project with a venv. A serializer-level payload with python_runtime (all six fields) and a populated last_check validates too.
• Tests fail before the fix. Dropping the schema_version line makes 3 tests fail (2 in test_engine.py plus the new schema test).
• Still clean after #2464 landed. I merged current main (faea91a) locally: no conflicts in docs/contracts.md or tests/test_contract_hardening.py, and the contract, stability-docs and engine tests pass (106 passed, 4 subtests).
• Docs agree. output-formats.md, command-reference.md and stability-tiers.md agree, and the registry, contract runner and stability tests are all updated.

Three non-blocking notes are inline. The python_runtime one is pre-existing doc drift that this PR now sits next to, so a follow-up issue is probably the right place for it.

[codeforester]

Pre-existing doc drift, now part of a published contract (non-blocking, probably a follow-up issue). basectl workspace status never emits python_runtime: engine.py:329 calls workspace_project_statuses(workspace_root, manifest) without probe_venv, and that has been the default since runtime inspection began requiring consent (#2236). A uv project with a .venv reports venv: "present_unverified" and no python_runtime. But docs/python-manifest.md ("Workspace status python_runtime") still says the status JSON includes python_runtime for each ready project.

Keeping it optional in the schema is correct. But a consumer reading the docs alongside this new stable schema will expect a field that never appears. Either fix that doc section (it's the 4th doc surface for this contract), or file an issue to track it.

[codeforester]

Coverage gap (non-blocking). All three scenarios are happy paths with exit 0. The shapes most likely to drift are the non-ok ones, and none is exercised: manifest_path: null for a non-Base repo, a missing required/optional repo (repo: "missing", venv/manifest: "unknown", exit 1), an invalid manifest with issues, and url/default_branch metadata. I checked by hand that all of these validate today, but a future change to them wouldn't be caught. One more manifest case with a missing required repo, a non-Base dir and a URL'd repo (asserting returncode == 1) would cover most of the schema's optional surface.

[codeforester]

Contract clarity (non-blocking). With a manifest, project_count counts only repos whose manifest is valid/invalid. In my probe, 5 records gave project_count: 2 and repository_count: 5. That's existing behavior, but a reader of a schema now marked stable will likely assume project_count == len(projects). A description on project_count and repository_count would capture the rule.

Related: venv, manifest and repo are free-form strings even though the values come from a fixed set (manifest: valid/invalid/missing/unknown; repo: present/missing; ...). Leaving them open is defensible under the additive-change policy, because adding an enum value would otherwise be breaking. Even so, listing the known values in description would help consumers.