fix: a fixed preset outranks a default

[blaipr]

Which preset applies is decided by score, which is priority + 3 / + 2 / + 1 by how
specifically it matches. priority is administrator-set, 0 to 128, so a group preset at
priority 5 outranks a user-scoped one left at the default 0. That much is the feature: the
field exists to arbitrate across scopes and this does not change it.

What it quietly did was let a default outrank a rule. Only a fixed preset is a rule —
AccountPreset::checkPasswordPreset() and checkPasswordExpiry() do nothing at all unless
getFixed() is 1 — so a non-fixed preset winning the selection means no policy is enforced.
An administrator who marked a password policy fixed for one person, and separately gave
that person's group a non-fixed preset carrying default values at any priority above zero,
got no policy for them. Nothing anywhere said so: the losing preset is not refused, it is
simply not selected, and getByFilter() returns one row.

fixed leads the ordering now. Between two fixed presets, or two non-fixed ones, the score
decides exactly as before — this only changes the mixed case, which is the case where the
answer was wrong.

It is a change to which preset applies for an installation configured that way, which is
why it is stated here rather than buried: the alternative is a rule an administrator
explicitly marked as one, silently doing nothing.

Asserted on the emitted ORDER BY rather than against rows, for the same reason as the
tie-break test beside it — which row a database returns for a tie is its own business, and
a behavioural test passes on this MariaDB whether or not the query asked for anything.
Checked by dropping fixed DESC: the new test fails.