Matt Mabrey
cc64c88c3e
cmd_promote() changed a user's role with no audit trail, unlike the identical change from the web Admin Console (set_user_role() -> log_event(), action "role_changed"). Not a new privilege - anyone with container-exec access already has DB access directly, D16's own trust-tier reasoning - but there was no record of who ran it or what changed. Now writes an AuditLog row matching set_user_role()'s shape, tagged via:cli (mirrors JIT provisioning's via:okta_jit) since a container shell exec carries no signed-in identity to attribute the change to. Verified against a scratch SQLite db: audit row lands correctly, role change persists, the no-such-user refusal still exits 1 clean.