fix(settings): read security.totp_required as a boolean, and seed auth.default_role

[fylorn]

Two bugs found during the access-handler refactor (#48).

security.totp_required was never true

It is stored as a JSON boolean (seeded false; the admin UI writes true), but GET /api/auth/totp/status read it with get_string(...) == "true" — as_str() on a boolean is None, so required was always false. Now:

• a typed DynamicConfig::totp_required() in the boolean getter list, used by the status endpoint;
• both setting validators (admin API and DynamicConfig) require a boolean for this key, so a string "true" — which would read as "not required" — is refused with 400.

Grepped every get_string( call: no other setting is compared with "true"/"false".

Note: required drives the console's notice asking users to enable TOTP; the server does not otherwise enforce the setting at login. That is how it was designed, not changed here.

auth.default_role could not be set

No seeded system_settings row existed, and the settings update only changes existing rows, so PATCH /api/admin/settings {"auth.default_role": …} reported success without effect. Seeded empty ("" = no role) in db/seeds.sql, which is applied idempotently on every boot like the other settings.

Tests

• requiring_totp_is_reported_to_users: status is false, a string value is refused, true via the admin API makes status report required: true.
• registration_assigns_the_default_role… no longer writes the row by hand before using the admin API.
• Both fail on the old code and pass with the fix.
• Local: fmt, clippy (--all-targets, --lib), 688 unit tests, full integration suite (342 passed) on own containers.

🤖 Generated with Claude Code