Keep a merged Lorentz structure out of the UFO module, so customize_model accepts SMEFTatNLO-NLO

[oliviermattelaer]

The refusal

MG7> import model SMEFTatNLO-NLO
MG7> customize_model --save=top          # then just `done`
Two restrictions of the model done with different input values do not lead
to the same model.  Difference(s) found for: interactions
...
InvalidCmd: customize_model can not be applied to this model.

Only from -NLO: from SMEFTatNLO, -NLO_no4q, -LO or sm it works. Found
while adding a customize_model step to the bsm tutorial (#165), which now
uses SMEFTatNLO-NLO.

What differed

Nothing physical. With ADMIN_DEBUG on, the two restrictions had the same
t t~ g g vertex, same couplings, same Lorentz structures but one:
FFVV1111 in the first build, FFVV1112 in the second. Neither name is in the
UFO — the restriction merges structures (RestrictModel.add_merge_lorentz) and
names the result.

Why the name moved

The first build leaked it. A UFO Lorentz registers itself in its
object_library.all_lorentz on construction — a module global, cached in
sys.modules for the rest of the process. RestrictModel.add_lorentz never
took its structure back out, so each import of the same restricted model
started with the previous one's merged structures already defined, grew by
them, and numbered its own one further on:

import_ufo.import_model(SMEFTatNLO, restrict=restrict_NLO.dat)   x3
  before:  658, 661, 664 Lorentz structures   (FFVV1111 left in the UFO module)
  after:   658, 658, 658

Instrumented: all three leaked structures per import come from
RestrictModel.add_lorentz; the 55 created by UFOMG5Converter.add_lorentz
don't, because it already swaps all_lorentz out while constructing. This
applies the same guarantee to the restriction's own structures.

Effect

• customize_model --save from SMEFTatNLO-NLO goes through and writes its
  restriction card (checked on a copy of the model; main still refuses).
• A long session — the tutorials, a script importing the same model twice — no
  longer carries one import's merged structures into the next.

Checked

• New test in test_import_ufo.py: a merged structure lands in the model and
  not in the UFO library it was built from. It fails without the fix.
• Every unit test file touching restrictions or import model (1464 tests):
  unchanged. The 3 TestRealRunNumbers failures need a madspace build this
  worktree doesn't have.

🤖 Generated with Claude Code