Three Qobuz Connect fixes

[Gjuju]

Three Qobuz Connect fixes

All found while testing Qobuz Connect on 10.3.4.

1. The Qobuz active flag is never reset. In worker.php, the startup reset that clears every renderer flag lists param='qbzctive', which matches nothing. qbzactive is therefore the only flag that survives a worker restart: when the worker restarts while Qobuz Connect is active, the Renderer Active overlay comes back with nothing playing and stays until the flag is cleared by hand.

2. isQobuzUpgradable() queries the wrong package. In renderer.php, it reads the installed version of librespot and compares it against the qobuz-connect entry in cfg_plugin. The two can never match, so the function always reports that an upgrade is available.

3. renderer.php startQobuz() — reads quality_fallback_behaviour (British)
while the schema row, qbz-config.php, the template and autocfg.php all
spell it behavior. It is the only British spelling in the tree, so the
lookup returns nothing and the daemon gets the command with no value:

  qbzd settings set audio.quality_fallback_behavior
  error: the following required arguments were not provided: <VALUE>

sysCmd() discards that, so the Quality fallback behavior selector never
reaches the daemon.

Validation

Measured on x86_64 and on a Raspberry Pi running stock 10.3.4, same method:
set the daemon to the value moOde does not want, then run startQobuz().

code	daemon before	daemon after
as-is	always_fallback	always_fallback — the configured value never arrives
fixed	always_fallback	always_skip — the configured value lands

The other two changes are code reading only.