feat: threaded replies to Posts — Reply entity + endpoints

[arturasmckwcz]

Context

fe#892 (originally a flat post-only feed) was updated per prototype feedback (a proposal + a follow-up amendment, both from the same design walkthrough) to require threaded replies: reply to a post inline, replies-to-replies grouped beneath their parent reply, and a reply count covering the full conversation. The current Post entity (src/data/entity/post.entity.ts) is flat — author, text, tagged persons, linked opportunities — with no parent/reply relationship, so this needs new backend work before the FE side can be built.

Blocked on need4deed-org/sdk#213 — per shared-rules.md, the contract (types + endpoint shapes) must be defined and published in the SDK before this is implemented, not just before FE consumes it.

Scope

• New PostReply entity with:
  • text, author" (Person), post` (the root Post being replied to)
  • parentReply (nullable self-reference) — a reply-to-a-reply still belongs to the root post but nests one level under its parent reply, matching the prototype's "grouped beneath their parent reply" behavior (no deeper nesting than that)
• Endpoints: POST /post/:id/reply, PATCH /post/reply/:id, DELETE /post/reply/:id
• Decide whether GET /post/GET /post/:id inlines replies or just a replyCount, with replies paginated separately — depends on expected reply volume per post
• Implement against the types published from feat: contract types for Post replies (ApiPostReply*) sdk#213

Acceptance criteria

• feat: contract types for Post replies (ApiPostReply*) sdk#213 published and this depends on the published version (not a local/linked SDK)
• Schema change proposed and confirmed necessary/semantically correct before writing the migration (per shared-rules.md)
• Reply CRUD endpoints exist and are documented in swagger
• Migration replays cleanly on a fresh DB (docker compose down -v && RUN_MIGRATIONS=1 docker compose up)

Blocked on: need4deed-org/sdk#213
Referenced from need4deed-org/fe#969