Add Intel AMX exact-device lane

[gstoner]

What changed

• move the AMX INT8 K>64 regression from the hermetic unit suite into tests/device/x86
• isolate native AMX execution in a child process so SIGILL or a runtime fault cannot crash the pytest worker
• add a local, fail-closed Intel AMX exact-device gate that records machine identity and runs correctness twice without xdist
• add static release-gate ratchets and update the validation architecture and X86-3 audit plan

Why

The portable PR lane correctly excludes hardware_amx, but the regression had no owning exact-device command. That made the required lane green by deselecting a known wrong-result regression. This PR gives the marker an executable owner without claiming evidence from the current non-AMX host.

Validation

• 31 passed — AMX gate contract, suite architecture, relocated regressions, and audit docs
• 53 passed — test-document and generated-document drift gates
• 1 test collected for tests/device/x86 -m hardware_amx
• 24 generated documents in sync
• current AMD WSL host rejects the AMX gate with exit code 2 instead of skipping

Exact-device evidence

Not yet available. X86-3 remains access-gated until a named Intel AMX host runs scripts/run_x86_amx_release_gate.sh and supplies the retained correctness packet. A measured-performance gate and baseline also remain open.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bd04708a45

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Install fallback dependencies in the selected AMX venv

When TESSERA_X86_AMX_VENV points to a custom environment that is missing xdist or another required module, this fallback runs install_test_deps.sh --venv, which hardcodes installation into $ROOT/.venv, and then switches back to the still-incomplete custom environment. The subsequent pytest commands therefore fail, typically because -n is unrecognized, despite the gate reporting an automatic dependency setup path; either install into LOCAL_VENV or use the default environment that the helper actually populated.

Useful? React with 👍 / 👎.