chore(ci): switch auto-label to ministral-8b-2512, add model override input

[cyh7789]

What changed

1. Model switched to ministral-8b-2512 (was mistral-medium-latest)
2. New workflow_dispatch input model, overriding the model in label-config.yml so swapping models needs no file edit

This workflow has no pull_request trigger, so the "don't label PRs" part of the internal change does not apply here.

Why

The internal repo's identical workflow failed on every run with 429 Rate limit exceeded on mistral-medium-latest. That is on Mistral's side, not ours: the workflow fires a handful of times a day, nowhere near any plausible quota. The ministral models are a different, cheaper path that is currently working.

Model ids, measured

A throwaway probe step in the internal repo sent one minimal request per candidate:

ministral-8b-2512     -> HTTP 200
ministral-14b-2512    -> HTTP 200
ministral-3-8b-25-12  -> HTTP 400 Invalid model
ministral-3-14b-25-12 -> HTTP 400 Invalid model

/v1/models lists ministral-3b-2512, ministral-8b-2512, ministral-14b-2512 (plus -latest aliases).

Verification (dry-run on issue #43)

This repo's prompt also does spam and duplicate detection, so JSON compliance matters more here. Both models handled it:

ministral-8b-2512  → classified [feature, priority:P1, scope:ai, api], adding [priority:P1, scope:ai, api]
ministral-14b-2512 → classified [feature, priority:P1, scope:ai],      adding [priority:P1, scope:ai]

Runs 34920092114 (8b) and the 14b run right after it both completed successfully. 8b is the default here for cost and speed; switch to 14b by editing one line in label-config.yml or by passing the model dispatch input.

Known limitations

• Only one issue was classified per model. Comparing label quality at scale would need a full dry-run pass over all open issues.
• Spam and duplicate detection were exercised only on a non-spam, non-duplicate issue; neither branch was triggered in this test.