SUMMARY
Plasma workspace allows the user to set environment variables in .sh files located in ~/.config/plasma-workspace/env. However, if one sets a variable to the empty string, it does not get exported into the plasma process.

STEPS TO REPRODUCE
Put these into ~/.config/plasma-workspace/env/foo.sh and give it +x permission:

```bash
export SHOULD_BE_ONE=1
export SHOULD_BE_NONE=
```

Then boot KDE.

OBSERVED RESULT
SHOULD_BE_ONE is 1 but SHOULD_BE_NONE is unset.

EXPECTED RESULT
SHOULD_BE_NONE should be set to the empty string (should appear in the output of `env`).

SOFTWARE/OS VERSIONS
Operating System: NixOS 24.05
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.2
Graphics Platform: Wayland

ADDITIONAL INFORMATION

To fix the problem, arguably we should fix this function in `startplasma.cpp`:

```cpp
void setEnvironmentVariable(const char *name, QByteArrayView value)
{
    if (qgetenv(name) != value) {
        qputenv(name, value);
    }
}
```

`qgetenv` is documented to return the an empty byte array if the variable is unset, so `gputenv` is not called.

This behavior is not always problematic, but consider the following situation. Suppose some env var `X` is set in the DBus environment already, but the user would like to use the value they specified. `startplasma-wayland.cpp` does three things in order:

1. Source `env/*.sh` and import the env vars by calling `runEnvironmentScripts()`
2. Sync environment to DBus by calling `syncDBusEnvironment()`
3. Import systemd env vars by calling `importSystemdEnvrionment()`

If in the .sh file `X` is set, it should be imported into the plasma process in step 1, then exported to DBus in step 2, so step 3 just re-import that exported value, which is set by the user. However, if the user sets `X` to be empty in the script, then it won't get pass step 1, so the value from systemd will be used after step 3.