feat: per-project workflow settings, statistics and "my work" home

Per-project settings (owners/admins, «Configuración» tab):
- Statuses with category (TODO, IN_PROGRESS, QA, DONE, CANCELLED), colour and
  "requires reason"; configurable transitions; ticket types (icon, colour) and
  areas. Defaults are the previous fixed values; projects created before keep
  them without migration.
- Values are archived, never deleted: tickets, history and statistics keep
  referring to them. Validated in the domain (ProjectSettingsChangedEvent).
- Releases, board, tracking and "my work" use categories, so custom statuses
  keep working. Status changes carry name/category metadata for history.
- GraphQL: status/type/area are strings (breaking for clients sending enum
  literals); Project.settings, updateProjectSettings, statusCategory,
  myIssues(categories). REST: PUT /projects/{project}/settings, category filters.
- Read model: statusCategory on issues (backfilled at startup).

Statistics («Estadísticas» tab):
- New issue_timeline projection; pure functions compute created vs resolved,
  cumulative flow, cycle/lead time (avg + p85), throughput per person, QA
  pass/fail and release burnup. GraphQL Project.analytics(days),
  Release.burnup; REST /projects/{project}/analytics, /releases/{id}/burnup.
- Web: SVG charts with validated light/dark palette, crosshair tooltip,
  keyboard navigation, legend and data table.

Home "Mi trabajo": my open tickets across projects grouped by category (QA
failures first), tickets waiting for QA, upcoming releases and "Ir a…".

Tests: domain/application specs, e2e scenario for settings and analytics,
facade tests. Docs, READMEs, schema.gql/openapi.json and Word/PDF updated.

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

libs/api/tracker/domain/src/lib/read-models/analytics.read-model.ts

@@ -0,0 +1,58 @@
+import { StatusCategory } from '../project/project-settings';
+import { UserRefReadModel } from './user-ref.read-model';
+
+/**
+ * One step in a ticket's life (projected from its events): the raw material
+ * of the statistics. `status` entries record where the ticket went (with the
+ * category it had then), `release` entries which release it joined or left.
+ */
+export class IssueTimelineEntry {
+  /** Id of the event that produced it (projection is idempotent). */
+  id!: string;
+  issueId!: string;
+  projectId!: string;
+  at!: string;
+  kind!: 'status' | 'release';
+  status?: string;
+  category?: StatusCategory;
+  /** Assignee when the status changed (throughput per person). */
+  assigneeId?: string | null;
+  releaseId?: string | null;
+}
+
+export class DurationStats {
+  count!: number;
+  averageDays!: number | null;
+  /** 85th percentile: "85% of tickets take at most this long". */
+  p85Days!: number | null;
+}
+
+/** Statistics of a project over a period. */
+export class ProjectAnalyticsReadModel {
+  from!: string;
+  to!: string;
+  /** Per week (Monday): tickets created and tickets finished. */
+  createdVsResolved!: { week: string; created: number; resolved: number }[];
+  /** Tickets in each status at the end of every day (cumulative flow). */
+  cumulativeFlow!: {
+    dates: string[];
+    series: { status: string; counts: number[] }[];
+  };
+  /** From starting work to done. */
+  cycleTime!: DurationStats;
+  /** From creation to done. */
+  leadTime!: DurationStats;
+  /** Tickets finished per person and week. */
+  throughput!: { week: string; user: UserRefReadModel | null; count: number }[];
+  /** Tickets leaving QA: to done (passed) or back to work (failed). */
+  qa!: { passed: number; failed: number; failureRate: number | null };
+}
+
+/** Scope vs finished tickets of a release, day by day. */
+export class ReleaseBurnupReadModel {
+  releaseId!: string;
+  targetDate!: string | null;
+  dates!: string[];
+  scope!: number[];
+  done!: number[];
+}