v0.1.72

Store/config — 3 of 62 confirmed findings (8-10 of 62)

Re-derived from current code by a fresh investigation fork. Bundled into one PR since all three are small and land in the same subsystem.

Multi-role policy merge depended on incidental row order

EffectivePolicy's "first non-empty limits wins" rule scanned roles_policy with no ORDER BY — and that table has no precedence/priority column at all. Which role's limits applied to a user holding two roles with different non-empty limits depended on whatever order an unordered scan happened to return — a VACUUM, a changed query plan, or a Postgres version bump could silently flip it. Added ORDER BY role: this does not invent a real precedence model, it only makes the existing rule reproducible instead of accidental.

N+1 query in role-triggered snapshot rebuild

RebuildKeySnapshotsRole re-queried each affected user's roles individually even though its own initial query already knew every affected user's id. Extracted a shared applyKeySnapshot helper and had the role query return roles alongside each id, eliminating the per-user re-query.

Duplicate OIDC_ROLE_MAP key silently resolved last-wins

parseRoleMap resolved a repeated idp_role key via plain map assignment with zero validation or log line. Operator-typed config, not attacker-reachable, but an easy typo to make invisible — now logs a warning naming the key and both values. Behavior unchanged.

• Test: TestEffectivePolicyMultiRoleLimitsAreDeterministic, TestRebuildKeySnapshotsRoleAvoidsPerUserRoleQuery, TestParseRoleMapLogsDuplicateKey (all new)
• Surgical-revert proof: each of the three reverts genuinely broke its own test (wrong role's limits won; QueryRow count went from 0 back to 3; removing the warning removed the only use of log/slog in the file, failing the build)

Shipped via #146, chart bump #147.

Next up: Routing/fallback's 3 uncatalogued Minor findings — fresh investigation fork, same methodology.

Full Changelog: v0.1.71...v0.1.72