feat(article): drop the markdown body from list responses

[aquie00t]

What does this PR do?

ArticleItemSchema served both the detail endpoint and every list endpoint, so GET /articles and GET /articles/me returned the full markdown of every item. The schema caps a body at 100 000 characters, which makes a page of fifty articles megabytes of text no list view renders — and that was also what Redis cached for 60 seconds, per viewer.

Measured

Booted the app against the dev database with one 28 KB article:

response	before	after
GET /articles?limit=10	28 930 bytes	924 bytes
GET /articles/:slug	28 930 bytes	28 930 bytes (unchanged)

At limit=50 that is roughly 1.4 MB versus 46 KB per page.

How

• ArticleSummarySchema = FBType.Omit(ArticleItemSchema, ["body"]) — derived, not a hand-written twin, so a field added to the item schema appears here automatically.
• ArticleSummaryResponse = Omit<ArticleResponse, "body"> in the mapper, with toSummaryResponse holding every shared field and toResponse spreading body onto it. One place to change, so the two shapes cannot drift.
• Narrowing toListResponse's return type propagates through ArticleController.list / mine into the route Reply generics — so the type system enforces this, rather than fast-json-stringify quietly dropping a field it does not recognise.

The detail, create, update, publish and archive responses are untouched and still carry the body.

What is deliberately not touched

The repository selects. The repo uses include, not select, so body is still fetched from Postgres. Removing it there means switching to select, which breaks the ArticleWithRelations cast and Article.with(), which requires body: string. That cascades into either an optional body on the domain entity or a second read model — real work, unrelated to this.

The Redis cache DTO. Stripping body from CachedArticle would feed an empty string into Article.with(). If a body ever returns to a list response, cached pages would serve "" while uncached pages served real markdown — a bug that appears and disappears on a 60-second cycle. Both belong in one later change with an explicit summary read model.

Timing

Doing this now costs nothing: the article migrations have not been applied to production, so no client is reading these responses yet. Later, it would be a breaking change.

Verification

lint, format:check, build clean; 755 unit tests pass.

Three new e2e assertions in tests/e2e/article/read.test.ts: list items carry excerpt, coverImageUrl and readingTimeMinutes but not body; /articles/me likewise; and the detail endpoint still returns a non-empty body.

Verified end to end by booting the real app: create → publish → list → detail → the numbers in the table above.

---

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Chore

---

Checklist

• My branch follows the naming convention (feature/, fix/, chore/, docs/)
• My commits follow Conventional Commits
• I have tested my changes locally
• I have not introduced any breaking changes
• I have updated relevant documentation if needed

First of three: this one lands before the profile articleCount so the profile Articles tab is never shipped against megabyte pages.

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 1.7.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀