#217 feat: domain operations writing declared columns

[RAprogramm]

Closes #217

Columns that must change only through a named operation could not be #[field(update)] — that puts them in the public patch DTO and in the upsert SET list — so the only escape was raw SQL. A command can now declare exactly what it writes:

#[command(VerifyPassport, payload(passport_provider), sets(
    passport_verified = "true",
    passport_verified_at = "NOW()"
))]

Generates verify_passport(command) on the repository, issuing one statement:

UPDATE citizens SET passport_verified = true, passport_verified_at = NOW(), passport_provider = $1
WHERE id = $2 RETURNING …

Piece	Behaviour
sets(column = "expr")	fixed SQL expression, verbatim in the statement like #[column(default = "…")]
payload(column, …)	columns bound from the command struct
id	required — the operation targets one row; sets(...) implies requires_id
Soft delete	a deleted row is not touched
Unknown id	the row-not-found error, not a silent success

Column names in sets(...) are checked against the entity while parsing, with a compile-fail case covering the rejection. A live-Postgres case proves the fixed expressions apply, the payload column is bound, a column the operation does not name stays untouched, and an unknown id fails.

payload(a, b) is new alongside the existing payload = "Type"; the parenthesised form takes entity columns, the assignment form an external struct. README and the commands page in all five wiki languages document it.

[codecov]

Codecov Report

❌ Patch coverage is 91.33858% with 11 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...ity-derive-impl/src/entity/parse/command/parser.rs	70.96%	9 Missing ⚠️
...-derive-impl/src/entity/sql/postgres/domain_ops.rs	95.55%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!