feat(flydsl): skip strict COMMANDMENT correctness on translation runs

[peyron-amd]

Skip strict COMMANDMENT correctness on PyTorch→FlyDSL translation runs

Problem

A PyTorch→FlyDSL translation run already validates correctness with the
op-aware, scaled-tolerance translation harness. The downstream
second / COMMANDMENT harness then re-checks the same kernel with a
strict fixed tolerance and rejects translated kernels that are
actually correct (numerically equivalent within the op-aware tolerance).
This blocks otherwise-good translations from proceeding to optimization.

Change

Gate the strict COMMANDMENT CORRECTNESS phase behind the
GEAK_TRANSLATION_RUN signal:

• On a translation run: strict correctness is skipped (reported as
  correctness: "skipped"), while benchmarking still runs so we keep
  latency/speedup numbers.
• On non-translation runs (direct HIP/Triton --kernel-url): behavior
  is unchanged — the strict gate still applies.

Files

File	What it does
run/preprocess/translate.py / run/preprocess/preprocessor.py	Set GEAK_TRANSLATION_RUN=1 on a successful translation; emit GEAK_RESULT_* markers so the benchmark phase can still parse latency/speedup from the translation harness
run/postprocess/evaluation.py	Skip strict CORRECTNESS, keep benchmark; preflight smoke-tests [SETUP] only on a translation run
run/preprocess_v3/baseline.py	Skip the strict baseline correctness gate on translation runs
run/preprocess_v3/adapter.py	Allow preprocess to proceed into optimization past a harness-verifier correctness rejection on a translation run
tests/postprocess/test_translation_gate.py	Deterministic unit tests for the gate

Testing

• Unit: tests/postprocess/test_translation_gate.py covers the gating
  logic standalone (translation runs skip strict correctness; non-translation
  runs enforce it; preflight selects the right sections). These pass without
  the full pipeline / GPU.
• End-to-end: validated in a full geak PyTorch→FlyDSL run (level3/1_MLP,
  claude-opus-4.6, full mode). Observed live:
  GEAK_TRANSLATION_RUN=1 — smoke-testing SETUP only (strict CORRECTNESS skipped),
  with the run proceeding into the optimization stage and benchmarking intact.

Dependency / ordering

This gate is only exercised end to end once translation reaches the second
harness, which relies on the FlyDSL translation→optimization pipeline fixes in
#275 (per-run _opt_repo staging, reference-kernel staging, etc.). This
branch is intentionally a clean delta on top of #275 — it does not
include any #275 code. The two only touch the same files in distinct regions
(translate.py, adapter.py), so they should merge cleanly; recommend landing
#275 first, then this.