ci(security): pin the ScanCode install; pluggy 1.7.0 breaks it

[DeusData]

Summary

security / license-gate fails on every run since 2026-10-15 09:50 UTC, whatever the tree. The gate itself is fine: the scanner never starts.

FAIL: scancode run failed:
  ...
  File ".../plugincode/pre_scan.py", line 30, in <module>
    pre_scan_plugins = PluginManager(
  File ".../pluggy/_manager.py", line 366, in add_hookspecs
ValueError: did not find any 'pre_scan' hooks in <module 'plugincode.pre_scan' ...>

Cause: _security.yml ran pipx install scancode-toolkit unpinned. pluggy 1.7.0 was uploaded to PyPI at 2026-10-15T09:50:56Z. plugincode 32.0.0, which scancode-toolkit 32.5.0 requires, applies its HookspecMarker to a class (@pre_scan_spec class PreScanPlugin). pluggy 1.7.0 no longer finds a spec declared that way and raises at import.

• Last green gate: PR run 38715780017, job started 09:50:14Z, 42 s before the upload.
• First red seen: fix(daemon): settings startup survives busy and interrupted writes #2650, job 116530738085, 16:08Z.

Change

• .github/scancode-constraints.txt (new): pluggy==1.6.0, with the reason.
• _security.yml, license-gate: pipx install scancode-toolkit==32.5.0 with PIP_CONSTRAINT set to that file. 32.5.0 is the version every green run installed; an exact pin also keeps the 33.x line out until it is chosen on purpose.
• scripts/license-gate.sh: the "Requires" comment and the not-installed hint name the same command.

Proof

• Minimal local repro, plugincode 32.0.0 (its own pre_scan.py):
  • with pluggy 1.7.0, import plugincode.pre_scan raises the exact CI ValueError;
  • with pluggy 1.6.0 it imports, with one hookspec registered.
• pipx passes the constraint through: PIP_CONSTRAINT=<file with pluggy==1.6.0> pipx install pytest (pytest depends on pluggy) installs pluggy 1.6.0; the same install without the variable gets 1.7.0.
• The pinned pair, scancode-toolkit 32.5.0 with pluggy 1.6.0, is the set every green gate run installed up to 09:50 UTC today.
• The full ScanCode run was not repeated locally. This PR's own license-gate job runs it, since a workflow change selects every lane.

CI scope

• Gating: no new job and no new gate. This restores an existing gating job (ci-ok and the release verify both need security) that is red for every PR.
• Cost: unchanged: the same ubuntu job and the same steps.
• Flake surface: smaller. The install is now pinned instead of following PyPI.
• Trigger: unchanged.

Found, not fixed here

• Only scancode-toolkit and pluggy are pinned. The rest of scancode's dependency tree still floats, so another upstream release can break the gate the same way. A hashed lock file for the install would close that.
• license-gate.sh --selftest plants a structural violation only, so it reported OK while ScanCode could not start. The real gate still failed closed, which is correct, but the self-test does not prove the ScanCode layer runs.