fix(portal): count only open posts beside a board

[theRealBithive]

What changes

The number beside a board in the portal sidebar counted every post the viewer was allowed to see, while the list under it hides complete and closed posts by default and never shows a post that was merged into another. A board read "3" over two visible posts.

The count now applies the same default as the list: a post counts when it has no status or an active-category status, and is not merged, deleted, or hidden from the viewer by moderation. The status predicate moves into post.portal-default-status.ts, and both the list and the count read it from there, so the two cannot drift apart again.

After deploying: the portal sidebar shows smaller numbers on boards with completed or closed posts. Settings > Boards and GET /api/v1/boards keep counting every post; the apps API does not expose a count. A status filter chosen in the portal does not change the number beside a board — it describes the default view.

Contract

V1–V7 are in the header of board-public-post-count.db.test.ts, verbatim as confirmed; every test names its number. A fast-check property (100 runs, up to ten generated posts per board across status category, deleted status row, merged, deleted, pending; anonymous and team viewer) checks the count against the existing list function and against a number computed from the seed alone.

Measured

• Diff coverage: 3 executable lines, 0 never executed — PASS.
• Mutation gate on post.portal-default-status.ts: 3 mutants, 3 killed, 0 survived, 0 never executed — PASS.
• board.public.ts and post.public.ts are reported by name as not mutation-graded (declaring them would assert suites pin getPublicBoardBySlug, countBoards and error strings this change never touched). The five join lines this change touched in board.public.ts were checked by hand instead: five mutants applied one at a time, five caught by the new suite.
• Typecheck, oxlint, prettier: clean.

🤖 Generated with Claude Code