Epic: primitive modules, the cross-cutting blocks any system reuses

barakoCMS today ships CMS-shaped modules. To let people build a CRM, a surveying tool, a membership system, or a back office on the same core, it needs the primitives that are common to almost every application, not just content sites.

A primitive module is one thing, small, with a stable contract, that many different products assemble from. The test for putting something here: name three unrelated systems that would all reuse it. If you cannot, it is a product feature, not a primitive.

## The primitives (each gets its own issue)

Already tracked, part of this set:
- Forms and submissions (#110), Media library (#113), URL redirects (#112), Webhooks (#95), SMTP email (#125), Import/export (Portability, shipped)

To build (filed alongside this epic):
- Contacts: people and organizations, the universal party record a CRM, a survey, a membership app all need
- Notifications: in-app and delivered, so any module can tell a user something happened
- Tagging and taxonomy: label and categorize any record, shared across modules
- Comments and notes: a thread or activity note attached to any record
- Full-text search: keyword search over content and module records (distinct from the AI semantic module)
- Scheduling and reminders: time-based triggers any module can hang work off

## What makes each one a real module, not a stub

Each ships as its own NuGet package, depends only on the core, registers through the module contract, carries tests and an admin screen, and exposes its data through the same public delivery and RBAC surface as content. The module-author template (#84, #174) is the on-ramp; these primitives are also the proof that the template is good enough for someone outside the team to build the next one.

Not in the 4.0.0 stability milestone: v4 is hardening the existing surface. These are new capability and land after, on the primitives track.