fix(scoring): match labelMultipliers keys as fnmatch globs

[galuis116]

Summary

Fixes #1273.

The score preview resolved a repo's configured labelMultipliers keys by exact string equality, but the upstream gittensor validator matches them as fnmatch glob patterns (gittensor/validator/oss_contributions/label_resolution.py: fnmatch(label.lower(), pattern.lower()), returning the highest matching multiplier). So a repo configuring a wildcard trusted label — type:*, kind/*, priority:? — had every such label scored at the neutral default in the preview, making estimatedMergedScore diverge from what the validator actually awards (a 33% under-estimate for a 1.5 boost; the inverse error when the default is a penalty). Upstream explicitly tests these patterns (kind/* -> kind/bug, type:* -> type:bug-fix, *-dev -> backend-dev, 3.*/feature -> 3.0/feature).

What changed

• selectLabelMultiplier now matches each configured key against the PR's labels via a new labelPatternToRegExp helper that ports Python fnmatch semantics: * = any run, ? = one char, [seq]/[!seq] = character class, all other characters literal, anchored and case-insensitive. The highest matching multiplier still wins (mirrors upstream max(...)).
• The existing path-glob in change-guardrail.ts is deliberately not reused: it is segment-oriented (* stops at /, ? is literal), which is not fnmatch — labels are flat strings, so */? must span every character.
• Literal keys are unaffected — a pattern with no glob metacharacter compiles to an exact match, so every existing config scores identically (no behavior change for current registry data, which uses only literal keys).

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue ([Bug]: score preview matches labelMultipliers keys exactly, but the validator matches them as fnmatch globs #1273).

Validation

• git diff --check
• npm run actionlint (via npm run test:ci)
• npm run typecheck
• npm run test:coverage locally; the new helper + matcher have both-branch coverage (wildcard, ? single-char hit/miss, [seq]/[!seq] class, unclosed-bracket-as-literal, escaped metacharacter, multi-match max, and literal-key parity). The only uncovered lines reported in preview.ts are pre-existing and outside this diff.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check (no schema change — this is internal scoring logic)
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate (0 vulnerabilities)
• New behavior has unit tests for new branches, fallback paths, and the literal-key parity boundary

If any required check was skipped, explain why:

• None skipped; full npm run test:ci is green (4074 passed).

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no such changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A — internal scoring logic, OpenAPI unchanged.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section. (N/A — no visible UI change.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (N/A.)

Notes

• The fix is confined to src/scoring/preview.ts; no schema, migration, binding, or guarded-path changes. Registry normalization already preserves pattern keys verbatim, so wildcard keys now resolve exactly as the validator scores them.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.40%. Comparing base (e94a1a3) to head (86aea01).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1277   +/-   ##
=======================================
  Coverage   95.40%   95.40%           
=======================================
  Files         193      193           
  Lines       20949    20971   +22     
  Branches     7575     7580    +5     
=======================================
+ Hits        19986    20008   +22     
  Misses        383      383           
  Partials      580      580           

Files with missing lines	Coverage Δ
src/scoring/preview.ts	98.92% <100.00%> (+0.09%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JSONbored]

Real preview-vs-validator parity gap, distinct from the casing PRs — the labelPatternToRegExp translator handles the fnmatch corners and the test pins literal-key parity. Merges for base gittensor:bug; #1273 is slop-closed in the ring, so no multiplier.