SPEC v0.4: M2a and M2b decisions, handoff to the real state

Records the decisions proposed in the M2a (fdf2093) and M2b (fad6fc9)
reports: D-005 OpenAPI equality normalisations and CommonRules, D-006
bp_sum_not_10000 token, D-007 per-crate no-unwrap deny, D-010 Roborazzi,
D-011 IncompleteCustomRangeException, D-012 Room 3 with M2b's entities and
1.json as a contract file, D-013 JDK 25 Robolectric flags, D-014
failOnNoDiscoveredTests (D-008, D-009 unused). Clarifications in §6, §8.2,
§8.6, §9.6, §10.3, §10.4, §11, §14.2, §14.3, §14.5, §14.7, §14.8 and
AC-11.7. PLAN-M5 builds on the existing entities; v0.4 readings added to
PLAN-M3, M5, M7b to M7f. HANDOFF rewritten: next free D-040, spec v0.5,
server schema 2, Room schema 2.

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

PLAN-M7d.md

@@ -29,6 +29,7 @@ Build `:feature:settle`: settle up, global and per account (S-9), and the settle
 - Per-account settle-up: exactly one fixed allocation, amount defaulting to the absolute account balance, direction to the user who owes in that account (AC-11.4).
 - Over-settling is allowed, warned per row ("This settles more than is owed in <account>") and repeated in the confirm dialog (AC-11.5).
 - Settlements can be created, edited and deleted offline; editing recomputes with the edited settlement excluded (AC-11.6).
+- Validation errors come back as `SaveResult.Invalid` with §14.5.3 tokens, `required`, or `validation_failed` for a §9.6 limit without a domain token (note length, date) (§9.6, §14.2.4).
 - The proposal may leave accounts non-zero when the payer is owed somewhere; that is intended (§9.4 Consequences).
 - Detail shows payer, recipient, amount, date, note, allocations per account, and the timeline (§13.3 S-10, AC-12.4, AC-12.5).