feat(profile): expose published articleCount on the profile response

[aquie00t]

What does this PR do?

The profile carried followersCount, followingCount and postCount but said nothing about articles, even though the article feature has been merged for several releases. GET /api/v1/profiles/:username now also returns articleCount.

Published-only, and the same for everyone

The count excludes drafts and archived articles — including when the viewer is the owner. Two reasons:

• A total that included drafts would leak both the existence and the volume of unpublished work, which is exactly what the published-only rule on every public path exists to protect.
• A viewer-dependent number would be unstable, and it would fork a code path that is otherwise identical for owner, stranger and guest.

An author's own draft count is available as the meta.total of GET /articles/me?status=DRAFT.

E2E pins all of this: a draft does not move the number, publishing does, archiving moves it back down, and owner / stranger / guest all see the same value.

The query

countPublishedByAuthorId is a single prisma.article.count({ where: { authorId, status: PUBLISHED } }), covered exactly by the existing @@index([authorId, status]). It joins the Promise.all that already fetches the follow status and the post count, so the profile still makes one round of parallel queries.

Deliberately not findAll({ authorId, limit: 1 }) reading total — that would run a findMany with the full relation include just to produce a number.

Note for review: this class of change is not type-checked

Adding a required property to ProfileItemSchema without populating it in the controller makes fast-json-stringify fail serialization → 500. TypeScript does not catch it: controller methods take a bare FastifyReply, so send() is never compared against the route's response generic.

The e2e test is the only thing between that and a production 500, which is why this PR adds four of them.

Verification

lint, format:check, build clean; 759 unit tests pass (755 + 4 new).

• Unit — articleCount comes from the repository, is called with profile.userId, is identical for owner/stranger/guest, is reported alongside postCount rather than instead of it, and is not queried at all when the profile does not exist.
• Integration — countPublishedByAuthorId counts published only, ignores drafts, drops back when an article is archived, ignores another author's articles, and returns 0 for an unknown id.
• E2E — the four behaviours above against real HTTP.

No DI, Cradle, route or app.ts change: GetProfileUseCase is asClass(...).singleton() and awilix CLASSIC resolves the new articleRepository parameter by name from the key already registered in persistence.di.ts.

Client contract for the profile Articles tab

No new endpoint. The existing filter already does this job, with cache invalidation wired into publish/archive/update/delete:

• Public tab → GET /api/v1/articles?authorUsername=<username>&page=&limit=
• Own drafts → GET /api/v1/articles/me?status=DRAFT

Second of three. Stacks on #213, which slims the list payload those tabs will be reading.

---

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

🤖 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 📦🚀