Normalise --rich_editing and --syntax_highlighting on user update as user create does #656

Follow-up to #637 (merged as 9408392). That PR made user create --rich_editing store what core compares against: src/User_Command.php:445-446 runs the value through FILTER_VALIDATE_BOOLEAN and writes 'true' or 'false'. user update still hands the raw string to wp_update_user() (src/User_Command.php:601-629, parent::_update() at :629), and core stores it as given (wp-includes/user.php:2514, :2516).

Core reads the two options as string literals:

• user_can_richedit() enables the editor only when the stored value is exactly 'true' (wp-includes/general-template.php:4200). So wp user update 5 --rich_editing=1 disables the visual editor for that user.
• The code editor is switched off only when the stored value is exactly 'false' (general-template.php:4317). So wp user update 5 --syntax_highlighting=0 leaves syntax highlighting on.

Both flags report Success: either way. The docblocks at src/User_Command.php:546-552 say "'true' or 'false' as a string literal, not boolean", which is accurate, but a flag that accepts 1 and 0 on create and silently inverts or ignores them on update is a trap.

Done looks like: update() normalises rich_editing and syntax_highlighting the way create() does before calling parent::_update(), the two docblocks say the same as the create one ('true'/'false' or 1/0), and features/user.feature has a scenario for each flag on user update with a numeric value. Same handling for syntax_highlighting on create while at it, since create does not touch it today.