fix(T-29): bound the trending digest, and stop declaring unreachable LLM fallbacks

[DamengRandom]

Closes #18. Both reported bugs reproduced against the real code paths first, then fixed, then re-measured.

1. One repo's tags could take down the whole trending digest

summary was capped at 140 chars in code, but tags — also written by the curator model — had no bound on count or per-tag length, in the schema or the builder. Telegram rejects a message past 4096 rather than truncating it, so a single verbose entry cost every repo in the digest, all saved with sent=false.

The exact payload from the issue, before and after:

7 normal repos + 1 with a verbose tags array
  before : 4107 chars → Telegram rejects, all 8 lost
  after  : 2647 chars → delivered, 8 of 8 repos kept

Three parts:

• Bound the model-written fields. TRENDING_TAGS_MAX (5) and TRENDING_TAG_MAX (24); the existing magic 140 becomes TRENDING_SUMMARY_MAX. Scraped fields are left alone — GitHub bounds those itself.
• A trim guard in buildTrendingMessage that drops repos from the end until the message fits. The per-field caps cannot guarantee this on their own, because escaping runs after them and expands text: 140 & characters become 700. There's a test for exactly that path. A short digest beats no digest.
• Extracted buildTrendingMessage from the tool's func, mirroring buildAiNewsMessage, so it's testable without stubbing fetch.

Deliberately not done: adding .max() to TrendingRepoOutputSchema.tags. curator.graph.ts:8 validates the model's output against that schema inside a retry loop, so a cap there turns "returned six tags" into a validation failure and a wasted retry — possibly failing the job. Truncating in code degrades gracefully; rejecting in the schema doesn't.

2. The third LLM fallback was unreachable

LLM_FALLBACK_MODELS declared three models, but OpenRouter caps its models list at three entries including the primary, so createLlm's slice(0, 3) silently dropped the last one:

configured : [nemotron-3-super, gemma-4-31b, gpt-oss-20b]
actually sent : [nemotron-3-ultra (primary), nemotron-3-super, gemma-4-31b]
silently dropped : [openai/gpt-oss-20b:free]

Not a crash — configuration that reads as a safety net and isn't one. Cut to a single fallback, which is what the cap leaves room for.

3. Schema created before every job

CI never runs pnpm run setup, so a job shipping a new table hit relation ... does not exist in production. initDb is idempotent, so paying it per run is cheaper than the failure mode it prevents. Separate commit.

Verification

• pnpm exec tsc --noEmit — clean
• pnpm format:check — clean
• pnpm test — 62/62 pass, 9 new. news-telegram.tool.ts had no test file at all; it now has 8 cases including the reported payload and the escape-expansion path. createLlm had no coverage; one test now asserts every configured fallback actually reaches OpenRouter, so this can't regress if the list is lengthened.
• Live run: 26 repos scraped → top 8 curated → Telegram digest delivered → 8 rows saved with sent=true. initDb ran first, exercising the change in part 3.

Note on the issue's discarded candidates

The four killed candidates were correctly killed — the two NaN ones are structurally unreachable as described. One thing worth picking up separately: company-db.ts:29 says the table name "comes from env", but it's a hardcoded constant. Not a bug, but a comment that will mislead someone eventually.

Stacked note: #16 (T-28) is still open and also touches src/constants/index.ts — different hunks, so it should auto-merge, but whichever lands second may want a quick rebase.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F5CmYPdQcMeLzzJc3iDQ2u