[mise-lock] chore: migrate CI to mise-action

[krukonshedul]

Summary

• Adds mise.toml ([tools] python = "3.10") and generates mise.lock, in the versioned lockfile_version = 1 format mise 2026.8.11+ requires.
• Replaces actions/setup-python in python-package.yml with step-security/mise-action, pinned to v4.2.4 (mise CLI 2026.8.12).
• docker-build.yml has no toolchain-install step, so it is left untouched.
• .gitignore now excludes .github/actions.lock.yaml.
• Regenerated .github/actions.lock.yaml via alflow.

Judgment call

• No .tool-versions or existing mise.toml was present. python-package.yml tests a matrix of Python versions (3.7/3.8/3.9/"3.10") rather than a single pinned version. To preserve that matrix coverage, the mise-action step overrides the tool version per job via its mise_toml input (python = "${{ matrix.python-version }}"), following the same override pattern already used elsewhere in the org (see app-b2c-api-gateway's update-ampli.yaml). The root mise.toml itself pins python = "3.10" (the newest matrix entry) as the default/lockfile version.

Test plan

• CI passes on this PR (python-package.yml matrix jobs all green)

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	github/​step-security/​mise-action@​6e96d2ffbc65c037f23c78818f2a339d6cf830f7

View full report

[dyl-sv]

Blocking bug: in .github/workflows/python-package.yml, the second commit (5bac3b8, "pin mise-action to 2026.8.12") tries to pin the mise-action version but adds it as a second with: key on the "Setup mise" step instead of merging it into the existing with: block:

- name: Setup mise
  uses: step-security/mise-action@6e96d2ffbc65c037f23c78818f2a339d6cf830f7 # v4.2.4
  with:
    version: '2026.8.12'
  with:
    mise_toml: |
      [tools]
      python = "${{ matrix.python-version }}"

This is a duplicate mapping key, which is invalid YAML.

Evidence this is currently broken on HEAD (5bac3b8):

• The workflow run for this exact head commit (run 32952604392, confirmed via API to be attached to PR #7 / this head SHA) has conclusion "failure", completed in 0 seconds, with GitHub's own message: "This run likely failed because of a workflow file issue." No jobs ran — the workflow file fails to parse.
• gh pr checks 7 doesn't even list a "Python package" check for the current head, because the workflow is unparseable and never registers a check run.
• I independently parsed the file with a lenient YAML parser to sanity-check the duplicate-key semantics: a lenient parser silently drops the first with: block (silently discarding the intended version pin), while GitHub Actions' stricter parser rejects the file outright. Either way, the stated intent of the commit ("Pins step-security/mise-action to v4.2.4 (mise CLI 2026.8.12)") is not actually in effect, and CI cannot run at all on the current head.

This is a new regression introduced by this PR (specifically the second commit), not pre-existing: master's prior "Python package" failures were ordinary test failures under the old actions/setup-python setup, a different failure mode than a workflow-file parse error.

Fix: merge into a single with: block, e.g.

with:
  version: '2026.8.12'
  mise_toml: |
    [tools]
    python = "${{ matrix.python-version }}"

Please fix and confirm a green run on the resulting head commit before re-requesting review.

[dyl-sv]

Re-verified from scratch on head SHA f874c93.

Good news: the original defect is fixed. The "Setup mise" step in .github/workflows/python-package.yml now has a single merged with: block (version + mise_toml), the workflow file is valid YAML, and it actually runs — no more "workflow file issue" / zero-jobs failure.

However, CI is still red on this head SHA, so it does not meet the bar of "real jobs run and pass":

• build (3.8): mise itself fails to install — Failed to install core:python@3.8: No GitHub artifact attestations found for python@3.8.20. mise's attestation verification (default-on in 2026.8.12) rejects this specific python-build-standalone release.
• build (3.9) and build (3.10): mise install succeeds, but tests fail at collection — ImportError: cannot import name 'url_quote' from 'werkzeug.urls'. The mise-managed environment resolves a newer Werkzeug than the previous actions/setup-python + pip cache did, and Flask's installed version is incompatible with it.
• build (3.7): tests run further but still fail — 4 failed, 194 passed, 15 errors in tests/webhooks_test.py (TimeoutError against the webserver plugin), likely a knock-on effect of the same dependency drift.

Only the non-build checks (Socket Security, StepSecurity Optional Checks) are green.

Please pin/resolve the Flask/Werkzeug versions (or add an upper bound) so the wsview import works again, and either pin a python-build-standalone release that has attestations for 3.8.20 or set MISE_PYTHON_GITHUB_ATTESTATIONS=false / python.github_attestations = false for that toolchain. Requesting changes until the 3.7-3.10 matrix is green.