fix(article): match the tag filter case-insensitively

[aquie00t]

Problem

GET /api/v1/articles?tag=… matched the tag exactly, while GET /api/v1/posts?tag=… lowercased it first. Verified against production:

GET /articles?tag=nodejs  → 1 article
GET /articles?tag=NodeJS  → total: 0     ❌
GET /posts?tag=nodejs     → total: 20
GET /posts?tag=NodeJS     → total: 20    ✅

Tags are stored lowercased on both write paths (normalizeTags() for articles, the hashtag regex in PrismaPostRepository.create for posts), so any filter that is not lowercased matches nothing. A client that carries a tag's display casing into the URL — the trends list renders names as stored, but a hand-written or shared link need not — loses every article on that tag page while the posts beside them still appear.

Fix

• New normalizeTagFilter() in article-input.ts, next to the write-path normalizeTags(). Unlike that one it never throws: a malformed filter is a filter that matches no article, not a 400. A blank or whitespace-only filter becomes no filter, rather than a lookup for the empty tag.
• GetArticlesUseCase normalizes once and feeds the same value to both the repository call and the cache key.

Normalization sits in the use case rather than PrismaArticleRepository on purpose: the cache key is built before the repository is reached, so lowercasing at the repository would leave NodeJS and nodejs selecting the same articles under two separate cache entries.

get-my-articles carries no tag filter, so this is the only affected read path.

Tests

Six unit cases added — three on the helper (lowercase/trim, blank → undefined, malformed does not throw) and three on the use case (normalized tag reaches the repository, blank filter is dropped, two casings share one cache key).

pnpm vitest run --config vitest.unit.config.ts tests/unit/core/use-cases/article → 114 passed. Lint, tsc --noEmit and prettier clean. Integration and e2e left to CI.

Not in this PR

The client's /explore?tag=… page queries only /posts?tag=… and never /articles?tag=…, so tagged articles do not show there at all — that is a client-side gap, not an API one. Both endpoints support the filter, and /tags/trends and /tags/search already return postCount and articleCount separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XJ4fR79WAs2pxEYxY9uNY9

[github-actions]

🎉 This PR is included in version 1.12.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀