feat(users): weekly_hours + employment_type on user (Slice 1)

The blade template gates the capacity UI section behind Roles::admin, but the controller method that processes the form submission (likely update or a similar method) is not shown in this diff. If the server-side handler does not independently verify the caller has admin privileges before writing weekly_hours or employment_type, any authenticated user could craft a POST request to set these fields on any user (including themselves) via IDOR or direct param tampering. The buildValuesFromPost method in the diff reads these fields directly from $_POST without any ownership or role check. This would allow privilege escalation (setting employment type) and data integrity issues for downstream capacity planning.

The UsersRepositoryTest creates an anonymous subclass that duplicates the real editUser method's updateData construction logic (lines 174–202). While it bridges to the private normalizers via reflection, the core partial-update guard (array_key_exists logic) is reimplemented rather than exercised through the actual production method. Any future change to editUser (adding a new field, altering normalization order) will not automatically cause these tests to fail, creating a false sense of coverage. Prefer to test via the public interface by mocking the DB connection, or extract the normalization and partial-update logic into testable helpers.