fix(ops,registry): honor feature_frame_version >= 3 (stop clamping to {1,2})

[w7-mgfcode]

Summary

Two feature-frame-version read helpers clamp any V outside {1, 2} down to 1, so a run with feature_frame_version >= 3 is mis-classified as V=1. This breaks the showcase stale_alias_trigger step and, more generally, ops staleness verdicts and registry comparability/duplicate detection for V≥3 runs.

Affected code

Both do if isinstance(value, int) and value in (1, 2): return value then fall through to return 1:

• app/features/ops/service.py:157 — _run_feature_frame_version
• app/features/registry/service.py:652 — _extract_feature_frame_version

Their docstrings say "Returns the int when the key is present, else V=1" — which the in (1, 2) guard contradicts. The registry SQL sibling _feature_frame_version_filter (service.py:710) already honors any int (v_column == feature_frame_version), so the codebase is internally inconsistent.

Reproduction (showcase_rich, fresh DB)

stale_alias_trigger registers a run with runtime_info_extras={"feature_frame_version": 3} (docstring: "V=3 is a valid synthetic value that fires the V-mismatch branch") and asserts the demo-production alias becomes stale_reason=feature_frame_version_mismatch. Instead it gets newer_success_run:

• alias → V1 naive run 8322305a
• grain's newest run b4ad4131 is V=3 in the DB, but _run_feature_frame_version returns 1 (3 ∉ {1,2})
• _alias_staleness: alias_v(1) == latest_v(1) → mismatch branch skipped → falls through to newer_success_run.

Result: the decision phase step 4/5 fails and showcase_rich finishes red.

Impact

• Ops /ops/summary reports the wrong stale_reason for any V≥3 alias.
• Registry comparability / _find_duplicate treat V≥3 runs as V=1 (could group non-comparable runs).
• Blocks a green showcase_rich run.

Fix

Replace value in (1, 2) with isinstance(value, int) and value >= 1 in both helpers (honor any positive int — matches the docstrings, the SQL filter, and the "opaque incrementing int" model in docs/_base/DOMAIN_MODEL.md).

Tests

• ops: _alias_staleness with a V=3 latest run vs a V=1 alias → feature_frame_version_mismatch (not newer_success_run).
• registry: _extract_feature_frame_version({"feature_frame_version": 3}) → 3.

Notes

Found during a showcase_rich dogfood on 2026-06-01; the step's strict assertion correctly caught the bug.

[w7-mgfcode]

Fixed in PR #339 and merged into dev. Closing manually (dev is not the default branch, so GitHub auto-close only fires on the next release merge to main).