feat(theme-global): add configurable active player tint

- add Templates Global intensity control with explicit off state
- tint active card backgrounds from the active border color across shared and special themes
- cover config, UI, preset and runtime behavior with targeted regression tests

Author: thomasasen

.agents/skills/repo-validation/SKILL.md

@@ -79,7 +79,7 @@ If shipped-source packaging or publication truth is in scope, also use `$userscr
 - if the change affects behavior, config, runtime, DOM, startup, update, or cache handling, run the narrowest repo commands that prove that scope
 - use `npm run lint` when a change touches linted JS/MJS source, tests, loader code, scripts, or lint configuration and the check would add signal beyond syntax/test coverage
 - use SonarQube validation when the change affects `src/**`, `loader/**`, `scripts/**`, `tests/**`, `sonar-project.properties`, or Sonar-specific repo guidance and the server is available; for these changes, treat Sonar as expected validation unless the work is docs-only and unrelated to Sonar policy itself
-- if SonarQube validation is chosen, prefer scanning project `xConfig` against the configured local server and report whether the scan ran, whether the server processed it successfully, and any material change in issue counts or gate status
+- if SonarQube validation is chosen, prefer the SonarQube server and project settings from `~/.codex/config.toml` instead of hardcoded scanner parameters and report whether the scan ran, whether the server processed it successfully, and any material change in issue counts or gate status
 - if SonarQube validation is chosen and the server returns open issues, bugs, vulnerabilities, or code smells for the touched scope, do not stop at the first scan result; iterate on fixes and rescans until those findings are cleared or a concrete blocker is reported
 - if SonarQube validation cannot run, state the concrete blocker such as unavailable MCP, missing auth, unreachable server, or scanner failure instead of reporting a generic skip
 - use release validation only when the task explicitly includes release, finalize, ship, package, publish, version bump, `dist/` refresh, or publication-state work

AGENTS.md

@@ -9,11 +9,11 @@ Priority: truthfulness, correctness, proportional validation.
 - work in source, not `dist/`
 - keep standard ESLint coverage scoped to actively maintained source; exclude archive, backup, vendor, and generated trees from the default lint surface
 - run `npm run lint` before declaring done when changes touch linted JS/MJS source, tests, loader code, scripts, or lint configuration
-- when changes touch Sonar-scanned JS/MJS source or project-level analysis config, treat a SonarQube check as part of the expected validation surface; prefer the configured `xConfig` project on `192.168.2.50:9005`, run it whenever server/auth access is available, and report it explicitly as executed or blocked rather than silently skipping it; treat Sonar as complementary to lint/tests rather than a replacement
+- when changes touch Sonar-scanned JS/MJS source or project-level analysis config, treat a SonarQube check as part of the expected validation surface; prefer the SonarQube connection and project data configured in `~/.codex/config.toml`, run it whenever server/auth access is available, and report it explicitly as executed or blocked rather than silently skipping it; treat Sonar as complementary to lint/tests rather than a replacement
 - when SonarQube reports new or still-open issues for the current work, fix them in-source and rerun the relevant local validation plus SonarQube in a loop until the touched scope is clean or a concrete blocker is reached; do not stop at a green quality gate if open issues, bugs, vulnerabilities, or code smells for the touched code still remain without explanation
 - never hand-edit generated files; refresh them only through the build flow when release work is explicitly requested
 - use `.agents/skills/repo-validation/SKILL.md` after changes to choose the smallest sufficient validation
-- when SonarQube access, project health, or issue triage is requested, prefer the configured local `sonarqube` MCP server or its configured base URL, use project key `xConfig` / project name `autodarts-xconfig` as the canonical mapping for this repo, and re-verify live server status and project visibility instead of assuming an earlier access check is still current
+- when SonarQube access, project health, or issue triage is requested, prefer the configured local `sonarqube` MCP server or the SonarQube base URL, project key, and project name from `~/.codex/config.toml`, and re-verify live server status and project visibility instead of assuming an earlier access check is still current
 - never copy SonarQube tokens or other local credentials into repo-tracked files; rely on local MCP or environment configuration instead
 - when browser access is available, Codex may use the connected Chrome browser for analysis, tests, DOM inspection, console, network checks, and task-focused interactions, but only in the currently active tab; do not use other open tabs, switch tabs automatically, open additional tabs, or navigate outside the active tab unless the task explicitly requires it, keep any browser-side changes minimal and limited to debugging, reproduction, verification, or UI tests, use extra caution before potentially destructive actions, and if browser access is unavailable, continue normally and state what could not be verified
 - use `.agents/skills/userscript-release/SKILL.md` only for explicitly requested release, finalize, package, ship, or publish work