Codegen runs every time, and its output must match what is committed - #705

Codegen is mtime-gated, and a fresh clone stamps every file at checkout -- so whether a
provider looks stale is decided by write order, not by its source. Measured on CI run
33024633546, ONE commit across six jobs:

  test (darwin-arm64)    159 files   30 providers
  quality-gate             9 files    1 provider
  test (linux-amd64)       9 files    1 provider
  test (linux-arm64)       0 files    0 providers
  test (windows-amd64)     0 files    0 providers
  test (windows-arm64)     0 files    0 providers

Nothing varied but which runner took the job. Half of them ran no provider generator at
all, and every generator validation rides along with that -- so which defects get caught
was luck. #697 has the receipt: darwin regenerated goast, caught a duplicate declaration
through validate_action_name_consts, and failed; linux skipped it and passed. Neither
declaration was build-tagged.

Touching sources, not deleting outputs
  The obvious lever is `rm -f $(NEW_OP_INVENTORY)` -- one output per provider, each the
  head of a grouped rule, list already maintained. It cannot work. The generated files
  hold the op.Announce*() call sites devlore-inventory scans, inventory is a prerequisite
  of the star binary, and `build/star: FORCE` rebuilds star every run. THE OUTPUTS ARE
  ALSO INPUTS, so deleting them destroys the bootstrap that would regenerate them. Tried
  it: inventory found 8 packages instead of 19, then failed with `no op.Announce*() call
  sites found`.

  Deletion would be safe with an LKG present -- STAR resolves to build/star.lkg when it
  exists and build/star: FORCE is never consulted. Not taken: CI has no LKG, and a check
  that depends on an artifact CI lacks is not a check.

  `make -B generate` also forces the rules and forces far more than the question needs,
  propagating into the build/star sub-make.

Verified
  make regenerate   159 files, 30 providers -- matches the darwin leg exactly
  make generate       0 files -- the mtime gate still skips unchanged providers
  check / test-race / test-scenario   all pass

…duces

Generated files are committed, CI never ran `generate` explicitly, and no step asserted
that generation produced no diff. Two consequences, both live until now:

  A stale committed .gen.go passed CI. Edit a provider.go, forget to regenerate, commit
  -- if the mtimes fell the wrong way, nothing noticed.

  When codegen DID run, CI tested the regenerated output rather than the committed
  output. The artifact under test was not the artifact in the repository, and the
  rewrite happened inside the build where nobody saw it.

The fix already existed in this file, applied to go.mod: run the tool, then assert
nothing changed. `make regenerate` forces every rule; `git diff --exit-code` holds the
committed tree to it.

One leg is the right scope
  Generated output is platform-independent -- it has to be, since the repository holds
  one copy. Confirmed rather than assumed: regenerating all 159 files on darwin
  reproduced the committed tree byte for byte. Forcing regeneration on quality-gate
  makes the generator validations fire deterministically there, and the diff makes every
  other leg's mtime-gated build safe, because the committed files are then known current.

A deletion the generator no longer emits also fails this check -- the #572 class of bug,
caught for free.

Proved it can fail before trusting it
  A check that has only ever passed is not a check. Removing one +devlore:claim directive
  from ui.Note changed pkg/op/provider/ui/gen/provider.gen.go, which the diff catches.
  Restored byte-identical afterward.

  Worth recording: the first probe edited a method doc comment and changed NOTHING --
  doc comments do not reach the generated artifacts. Stopping there would have concluded
  the check was broken.