Task: Add default_party_id field to the account entity

Add a default_party_id field to the account domain entity, backing SQL table, repository entity/mapper, so an account can designate one of its parties as the quick-login default. Protocol layer already exposes it for free, since get_accounts_response embeds ores::iam::domain::account directly and JSON encoding is reflection-based (rfl).

• domain::account (account.hpp) has an optional default_party_id (boost::uuids::uuid) — a soft reference to a party owned by ores.refdata, unset by default.
• account_entity (repository layer) has a matching optional string column mapping.
• account_mapper maps the field both ways (db entity <-> domain).
• ores_iam_accounts_tbl (SQL) has a nullable default_party_id uuid column.
• Protocol layer already carries the field, since request/response structs embed domain::account directly — no separate wiring needed for read paths.
• Build and existing ores.iam.core=/=ores.iam.api=/=ores.iam.service test suites are green against the new schema.

1. Add the field to domain::account, account_entity, and account_mapper (both mapping directions).
2. Add the nullable column to iam_accounts_create.sql.
3. Reconfigure/build with the environment's real preset (linux-clang-debug-make, per .env, not the gcc/ninja preset used by mistake at first) and recreate the dev DB so the schema change takes effect.
4. Run the ores.iam.* test suites to confirm nothing regressed.

• account.hpp is hand-written, not codegen'd from a model spec (only the account/party junction table is codegen'd via mustache templates) — so this was a direct multi-file edit, not a template change.
• No hard FK to refdata's party table: matches the existing IAM/Refdata service-boundary separation (soft reference, validated at the service layer, not the database).
• Initially configured/built against linux-gcc-debug-ninja, which isn't what this checkout's .env specifies (ORES_PRESET=linux-clang-debug-make). Corrected: reconfigured and rebuilt against linux-clang-debug-make and recreated the dev DB before running tests, so results are representative of what CI will use.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Added default_party_id (optional uuid, soft FK to a refdata party) to:

• domain::account (domain layer)
• account_entity (repository layer, optional string column)
• account_mapper (both mapping directions)
• ores_iam_accounts_tbl (nullable uuid column)

Protocol layer required no direct edits: get_accounts_response and friends embed domain::account directly, and JSON encoding is reflection-based, so the field is already carried end-to-end.

Verification: reconfigured/built against linux-clang-debug-make (the preset in this checkout's .env), recreated the dev DB to pick up the new column, then ran ctest --preset linux-clang-debug-make -R iam — ores.iam.api.tests, ores.iam.core.tests, ores.iam.service.tests all green (100% pass, 0 failed).