UserController used to bind request params directly to the User
domain, which would allow Grails' data binding rules, not our policy,
to determine which roles could be assigned.

Extract role IDs at the controller and pass them to the service as
explicit arguments; make the service reject any role-shaped keys still
in the params map (`rejectRoleKeysInParams()`) so the boundary
is enforced from both sides. A `popRoleParamsBeforeBinding()` helper
applies the same extraction pattern consistently in `save()` and
`update()`.

Consolidate the permission checks themselves into
`checkCanAddOrRemoveRoles()` and `checkCanAddOrRemoveLocationRoles()`,
used by every path that can change role assignments: `saveUser`,
`updateUser`, `saveLocationRole`, `deleteLocationRole`.

Role validation logic moves into `validateAndApplyRoleChanges()` and
`validateAndApplyLocationRoleChanges()`, which add and remove roles
one at a time to steer clear of any GORM/Hibernate cascade quirks.

`checkCanAddOrRemove*Roles()` takes the target `User` as a parameter so
validation errors attach to the right object. A new `rejectRoleChange`
helper throws `ValidationException` with a localized message that
UserController surfaces directly in `flash.message` instead of
re-localizing.

Separately, `user.edit` and `user.show` had no entry in any of
`RoleInterceptor`'s role lists. Any authenticated, browse-capable
user could reach them through the default fall-through path. Add
them to `managerActions` so the interceptor enforces at least
manager-level access for both. This gets exercise in a big Spock
table in `RoleInterceptorSpec`.

While I was in there:
- Hoisted `deleteLocationRole` logic from `UserController` into
  `UserService`.
- Added five message keys to clarify error conditions to users.
- Added Javadoc on `saveUser`, `updateUser`, and `rejectRoleKeysInParams()`
  to explain why role IDs must not travel inside the params map.
- Covered the controller/service boundary with a new
  `UserServiceRoleValidationSpec` exercising role assignment, role
  removal, and params-map rejection.
- Updated `UserControllerSpec` setup to stub `session.user`, since
  `saveUser`'s new signature reads `session.user.id` to identify the
  requesting user.
- Used idiomatic Spock in `RoleInterceptorSpec`: `@Unroll` hoisted
  to the class, `||` separator marking expected output, `assert` used
  in expectations that delegate via a helper method.

Signed-off-by: Matthew Pearson <matthewpearson@gmail.com>

- `user.list` now requires manager (was admin)
- `user.edit` now requires admin (was manager)
- `user.show` stays at manager

`RoleInterceptorSpec`'s expected-values table is updated to match.

`UserController.deleteLocationRole` no longer produces `/user/edit/null`
when it can't resolve a user id. It now falls back to the user list. I
don't know if this ever happened, but it was a straightforward enough
backstop to implement.

`UserService` now raises `ValidationException` when a role assignment
references an unresolvable role or location id, rather than silently
filtering it out or letting a downstream permission check NPE on a null
`Role`.

Added some more tests.

Signed-off-by: Matthew Pearson <matthewpearson@gmail.com>