feat: add core report fields to Mros entity (PR 1.1)

[TaprootFreak]

Summary

First of four small API PRs that prepare Mros for full goAML SAR export. This one adds the core report-content fields that appear in every goAML report:

• reportCode (string, default SAR)
• reason (long text — Darstellung des Sachverhalts)
• action (long text — Grund für Verdacht / Was haben Sie bereits unternommen)
• indicators (JSON-serialised string[] of goAML indicator codes, e.g. ["0002M","1004V","2008G","3004B","3005B","3007B"])

Accessors on the entity expose indicatorCodes as a typed string[] so callers don't see the raw JSON string.

reason, action, indicators are nullable so existing rows stay valid. DTO fields are optional; the create/edit flow on the frontend will enforce required semantics gradually.

Files

• mros.entity.ts — new columns + indicatorCodes getter/setter
• create-mros.dto.ts / update-mros.dto.ts — new optional fields
• mros.service.ts — maps indicators: string[] DTO → entity via setter
• migration/1776957972101-AddMrosReportFields.js

Roadmap

• PR 1.1 (this one): core report fields
• PR 1.2: personOverrides JSON column
• PR 1.3: Mros ↔ Transaction many-to-many
• PR 1.4: frontend edit page
• Phase 2: XML export + XSD validation + download endpoint

Test plan

• Migration applies cleanly (up + down)
• Existing MROS row still readable (all new fields null / default SAR)
• POST /mros with indicators array → stored as JSON string, getById returns row with indicators readable via indicatorCodes
• PUT /mros/:id with indicators array → updates correctly; with indicators absent → existing value preserved

[davidleomay]

Migration was missing!

[TaprootFreak]

Fix in #3627. Migration constraint name computed via TypeORM's hash formula (sha1('mros_reportCode').substring(0,27)) — verified against AddMros's existing constraints, so no future drift.