fix(tier): noAuth providers count as free; free filter returns empty …

[megamen32]

Summary

auto/<category>:free (e.g. auto/coding:free) was picking paid models
when no free candidates were present:

1. The legacy freeProviders list omitted the noAuth chat providers
   (opencode, mimocode, …) that all carry noAuth: true upstream.
2. When the free-filter yielded zero candidates, virtualFactory.ts
   silently fell back to the FULL pool — so the noAuth-free providers
   being missing meant the router fell through to the paid models.
3. A corrupted JSON row in the tier_config SQLite table was swallowed
   silently by try/catch in loadTierConfigFromDb.

Fix

• tierConfig.ts — deriveNoAuthFreeProviders() auto-derives free
  providers from NOAUTH_PROVIDERS where noAuth === true and
  serviceKinds is empty or includes "llm" (excludes veo-free etc.).
  DEFAULT_TIER_CONFIG.freeProviders is the union of LEGACY_FREE_PROVIDERS
  and the noAuth-derived set.
• virtualFactory.ts — when the auto filter yields zero candidates,
  default to an EMPTY pool. Legacy "fall back to full pool" behavior is
  preserved behind OMNIROUTE_AUTO_FREE_FALLBACK_TO_FULL_POOL=true.
• taskFitness.ts — getTaskFitnessWithSource strips a trailing
  -free suffix and re-queries arena_elo on the base id. So
  mimo-v2.5-free inherits mimo-v2.5's arena_elo score instead of
  falling through to the 0.5 wildcard floor.
• db/tierConfig.ts — loadTierConfigFromDb logs a structured warning
  on JSON.parse failure AND on Zod validation failure (with a 200-char
  preview). Function still returns null so the caller falls back to
  DEFAULT_TIER_CONFIG, but operators can now spot the corruption.

Tests

• tests/unit/autoCombo/suffixComposition-4517.test.ts (new) — 6 tests
• open-sse/services/tests/tierResolver.test.ts — +8 tests
• open-sse/services/autoCombo/tests/autoCombo.test.ts — +3 tests
  (free-alias resolution)
• tests/unit/db-tier-config.test.ts — +3 tests (warning assertions)

All 20 new tests fail without the production fixes and pass with them.

[gemini-code-assist]

Code Review

This pull request addresses issue #4517 by dynamically deriving free providers from NOAUTH_PROVIDERS, resolving '-free' model aliases to inherit their base model's ELO scores, and preventing silent fallbacks to the full pool when a ':free' tier filter yields no candidates. It also improves error handling and logging for corrupted database configurations. The review feedback points out a style guide violation regarding the placement of the new test file, which should be moved to the 'tests/' directory. Additionally, suggestions were made to simplify a confusing string length slice expression and to resolve an inconsistency in handling raw configuration strings within error-handling catch blocks to prevent potential runtime errors.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

According to the Repository Style Guide (Section 1, Line 7), all unit tests, integration tests, or Vitest files must strictly be placed within the tests/ directory (e.g., tests/unit/). Creating new test files under open-sse/services/ violates this rule.

Please move this file to tests/unit/services/autoCombo/suffixComposition.test.ts to adhere to the project structure guidelines.

References

1. ALL unit tests, integration tests, ecosystem tests, or Vitest files MUST strictly be placed within the tests/ directory. ^(link)

[gemini-code-assist]

The expression -"-free".length evaluates to -5, but it is highly non-standard and can be confusing to read. It is cleaner and more maintainable to use a descriptive constant or a direct negative number.

Suggested change

	const baseId = normalizedModel.slice(0, -"-free".length);
	const baseId = normalizedModel.slice(0, -5);

[gemini-code-assist]

There is an inconsistency in how raw is handled between the two catch blocks. In the first catch block, raw is assumed to be a string without any type checks, whereas the second catch block safely checks typeof raw === "string" and falls back to String(raw).

To prevent potential runtime TypeErrors if raw is ever not a string, and to maintain consistency, please use the same safe truncation logic in both blocks.

Suggested change

	const preview =
	raw.length > CORRUPTED_VALUE_PREVIEW_LEN
	? `${raw.slice(0, CORRUPTED_VALUE_PREVIEW_LEN)}…`
	: raw;
	const preview =
	typeof raw === "string" && raw.length > CORRUPTED_VALUE_PREVIEW_LEN
	? raw.slice(0, CORRUPTED_VALUE_PREVIEW_LEN) + "…"
	: String(raw);