occ user:setting cannot overwrite a user config value that was stored with a type #65005

Bug description

occ user:setting <uid> <app> <key> <value> fails with a TypeConflictException when the key already exists with a type other than mixed:

In UserConfig.php line 1262:
  conflict between new type (mixed) and old type (string)

The command still writes through the deprecated IConfig::setUserValue(), which stores the value as ValueType::MIXED. UserConfig::setTypedValue() only accepts a different type when the stored one is MIXED, so any key written through IUserConfig::setValueString(), setValueInt(), setValueBool() and similar can no longer be changed from the command line.

occ config:app:set already handles this for app config: it keeps the stored type and accepts --type to change it. user:setting has no equivalent.

This has been possible since IUserConfig was introduced in 31. It is now visible in practice because apps are moving off the deprecated API. For example, nextcloud/activity#2991 (merged on October 1) changed SetUserDefaults to write the notify_* defaults with setValueString() on the first login. Since then, occ user:setting <uid> activity notify_email_<type> 0 fails for every user who logged in after the app-level default existed. That breaks admin scripts and the integration tests of apps that set these preferences through occ (we found it in the LibreSign Behat suite against master).

Steps to reproduce

1. OC_PASS=Some-Pass-123 occ user:add --password-from-env alice
2. Store a typed value, as any app using IUserConfig does:

   \OCP\Server::get(\OCP\Config\IUserConfig::class)
       ->setValueString('alice', 'someapp', 'some_key', '1');

3. occ user:setting alice someapp some_key 0

Control: occ user:setting alice someapp other_key 1 followed by occ user:setting alice someapp other_key 0 works, because that key was created as mixed.

Expected behavior

occ user:setting updates the value and keeps the type already stored for the key, the same way occ config:app:set does for app config.

If the value cannot be converted to the stored type (for example abc for an int key), the command should report that clearly instead of throwing a type conflict.

Nextcloud Server version

36 (master). The command and the type check are the same on stable31 to stable35.

Operating system / PHP / Web server / Database

Debian/Ubuntu; PHP 8.3; Nginx; MariaDB 10.6. Also reproduced on GitHub Actions with MySQL 8.1, MariaDB 10.11, PostgreSQL and SQLite. It does not depend on the environment.

Additional info

Suggested fix: in core/Command/User/Setting.php, read the stored type with IUserConfig::getValueType() when the key exists and call the matching typed setter, converting the input like config:app:set does. Keep the current behavior for new keys and for keys stored as mixed. Optionally add a --type option as in config:app:set.

I'm happy to open a PR with this change and unit tests in tests/Core/Command/User/SettingTest.php if the approach sounds right.