refactor(api): buses only in services, atomic commands, @Prop schemas

- Mongo read models are @Schema/@Prop classes (SchemaFactory), still
  loose: the props declared are the indexed or shaped ones.
- CommandBus and QueryBus are used by the application services alone.
  Duplicating a ticket, bulk updates, CSV imports, proposals and
  emptying the trash chain several commands, so they are service
  methods now and their composite commands are gone; every command
  handler is atomic. No forwardRef is needed.
- The due-date and trash timers are entry points: they live in the
  presenters and call the services. The automations event handler has
  its own file and calls AutomationsService.
- The tracker's user directory asks IdentityService; the composition
  root hands the identity application module to the tracker
  infrastructure (withIdentity), with no global module.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/02-arquitectura.md

@@ -23,14 +23,23 @@ flowchart LR
 | `domain`         | Modelo y reglas de negocio; puertos que necesita el dominio                                                         | `domain`                                  |
 | `application`    | Casos de uso: services, commands/queries + handlers, proyecciones (API) o facades + stores (web), puertos de salida | `domain`, `application`                   |
 | `infrastructure` | Adaptadores **de salida** que implementan los puertos (bases de datos, Redis, Pireon, GraphQL)                      | `domain`, `application`, `infrastructure` |
-| `presenters`     | Adaptadores **de entrada** (resolvers GraphQL, controllers HTTP, guards, páginas Angular)                           | `domain`, `application`, `presenters`     |
+| `presenters`     | Adaptadores **de entrada** (resolvers GraphQL, controllers HTTP, guards, temporizadores, páginas Angular)           | `domain`, `application`, `presenters`     |
 
 Las reglas no son una convención: las comprueba `@nx/enforce-module-boundaries` en `eslint.config.mjs` (`npx nx run-many -t lint`).
 
 - `domain` solo puede importar `@nestjs/common` (por `@Injectable()` de las factories) y `@nestjs/cqrs` (por `AggregateRoot`).
   Nada de TypeORM, Mongoose, Redis, GraphQL, Angular, NgRx ni Apollo.
 - `application` no puede importar adaptadores (TypeORM, Mongoose, Redis, Apollo…).
-- `presenters` nunca importa `infrastructure` ni usa los buses CQRS: habla con los `*.service.ts` (API) o con las facades (web).
+- Los buses CQRS (`CommandBus`, `QueryBus`) solo los usan los `*.service.ts` de `application`; todo lo demás pasa por
+  un servicio: resolvers, controllers, temporizadores (recordatorios, papelera; por eso viven en `presenters`), el
+  handler de eventos de las automatizaciones y el directorio de usuarios del tracker (`IdentityService`). La única
+  excepción es el `EventsBridge`, que ejecuta los comandos que devuelven las sagas.
+- Los comandos son atómicos: un handler no ejecuta otros comandos. Lo que encadena varios (duplicar un ticket, la
+  edición en bloque, importar un CSV, las propuestas, vaciar la papelera) es un método del servicio, que ejecuta los
+  comandos uno a uno con su bus. Así no hay ciclos entre servicios y handlers, ni `forwardRef`.
+- Sin módulos globales entre contextos: el tracker recibe el módulo de aplicación de identidad en la raíz de composición
+  (`TrackerInfrastructureModule.withIdentity(...)`), el mismo con el que se monta ese contexto.
+- `presenters` nunca importa `infrastructure`: habla con los `*.service.ts` (API) o con las facades (web).
 - `infrastructure` nunca importa `presenters`.
 - Los contextos también están acotados: `tracker` puede usar `identity` y `shared`; `shared` no depende de nadie; la web
   no depende de la API (y viceversa).
@@ -125,6 +134,9 @@ sequenceDiagram
   que reentregar un evento no tiene efecto.
 - Las queries leen por los puertos `Find*Repository`. Los read models (`ProjectReadModel`, `IssueReadModel`…) están en
   `domain/read-models`.
+- **Esquemas**: clases con `@Schema()` y `@Prop()` de `@nestjs/mongoose` (`read-model.schemas.ts`,
+  `user.schema.ts`), en `strict: false`: cada documento guarda el read model entero y las props declaradas son las que
+  tienen índice o una forma que conviene fijar.
 - **Ids**: cada documento tiene `_id` (el `ObjectId` de Mongo, que no sale de la base de datos) e `id` con índice
   único, que es el id del dominio: el mismo uuid que el `stream_id` del agregado en Postgres. Todas las consultas van
   por `id`. En usuarios es el id de Pireon; en actividad, historial y avisos, uno compuesto que hace idempotente la