fix(std): match a group name literally in user.group

[haribo]

Summary

user.shellf:56 observed membership with grep -qx "$group" — a basic regular expression,
not a literal. Debian allows . in a group name, so a request for advg.b was satisfied by
membership of advgxb, and the def reported already over a user it never added.

grep -qxF -- "$group" now. -- as well, for the reason #639 needed it: a name starting with a
dash is otherwise read as options.

The same class as #598, which fixed exactly this in htpasswd.entry where a.b read another
account's hash. The shape survived here.

Test plan

test/e2e/plans/adverse-user.group-regex.shellf, verified red first:

RED   user.group(group=advg.b, user=advgrpuser) ok.already
        ! id -nG advgrpuser | grep -qxF -- 'advg.b'  → the user is not in it
green user.group(group=advg.b, user=advgrpuser) ok.added

Convergence proven on a second run with an ordinary group name: ok.added then ok.already.
The case also asserts the look-alike group is still there — usermod -aG appends.

One thing worth recording about writing the case. The setup's own guard — "assert the user is
not in advg.b before calling the def" — was written grep -qx and therefore reproduced the
bug under test: it matched advgxb, and failed the setup instead of the def. It is grep -qxF
now, with a comment saying why. A guard written with the defect it guards against is a case that
can only fail for the wrong reason.

go test ./..., test/changelog-rule.sh, test/e2e/def-coverage.sh green.

Also here: a misfiled changelog entry, moved

#667's entry for #658 landed in the published [0.14.0] section instead of [Unreleased].
Cause: since the v0.14.0 roll, [Unreleased] carries only ### Added, so "the first ### Fixed
in the file" is 0.14.0's. This PR gives [Unreleased] its own ### Fixed and moves the entry
there.

This is the same defect as #630, in the same place, four days later. Worth naming rather than
quietly fixing, along with why nothing caught it: test/changelog-rule.sh validates entries
inside [Unreleased] only, so an entry filed into a released section is invisible to it.
That gap is not closed here — it is a check worth writing on its own, and this PR is not it.

Closes #660