Fix stdoutEncode mangling non-string values used by REST API (#6054)

[ChrisJr404]

Closes #6054.

What broke

In commit 09fadc4 ("Minor improvement of stdoutEncode", 2025-12-31), the non-string branch of stdoutEncode changed from passing values through unchanged to coercing them with str():

elif not isinstance(value, str):
    value = str(value)

This breaks the REST API path. lib/utils/api.py overrides sys.stdout.write to call jsonize(value), which expects the original Python value (e.g. a dict). The existing call chain in lib/controller/controller.py:181 is:

conf.dumper.string("", {"url": conf.url, "query": ..., "data": ...},
                   content_type=CONTENT_TYPE.TARGET)

flowing through Dumper.string() → _write() → dataToStdout() → sys.stdout.write(stdoutEncode(...)).

After the regression, the API now returns Python repr() strings instead of structured JSON for value fields:

- "value": {"url": "http://example.com/foo", "data": "id=1"}
+ "value": "{'url': 'http://example.com/foo', 'data': 'id=1'}"

Any client parsing the documented response shape breaks.

The fix

Restore the pre-1.10 behavior of returning non-string, non-bytes values unchanged. This matches the else: retVal = value branch the previous implementation had.

The encode/decode round-trip below is meaningful only for strings and bytes — applying it to dicts/lists/etc. has never been correct.

Verification

>>> stdoutEncode(b'foobar')          # unchanged
'foobar'
>>> stdoutEncode('hello')            # unchanged
'hello'
>>> stdoutEncode({'url': '...'})     # was repr'd; now passes through
{'url': '...'}
>>> stdoutEncode([1, 2, 3])          # passes through
[1, 2, 3]

Added a doctest covering the dict case so this can't silently regress again.

python3 -m doctest lib/core/convert.py — all 38 tests pass.