Caught by running the validators against the real checkpoint the moment it
finished downloading:

  variant_problems('int8') -> ["INT8 weights exist only for avatar-1.5;
                               this checkpoint reads as the base model"]

That guard predates the quantise action and contradicts it: the model page can now
BUILD base_model_int8/ for any checkpoint, so the button would have produced the
weights and this would have refused to load them. The feature shipped one commit
ago with a gate that made it useless.

What decides it now is whether the weights are present, not which family wrote
them — upstream still ships INT8 only for avatar-1.5, and that is still accepted
without a local build, but a base checkpoint with base_model_int8/ is served too.
Without them the refusal names the remedy ("use Build INT8 weights on the model
page first") instead of stating a family rule the operator cannot act on.

The checkpoint directory is passed in for that, since the gate could not otherwise
see what had been built.

Checked against the real 78 GB download: checkpoint_problems is clean, the
vendored source passes source_problems, bf16 is ungated, int8 is refused before a
build and accepted after, and upstream's avatar-1.5 path is unchanged.

16 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY