fix: correct PGOPTIONS parsing and search_path handling

[b3b]

What kind of change does this PR introduce?

Bug fix: improves PGOPTIONS parsing to correctly handle both --key=value and -c key=value syntax, prevent malformed tokens, and avoid leaking unintended parameters to Postgres.

What is the current behavior?

Supavisor currently parses PGOPTIONS using URI.decode_query, but PostgreSQL does not URI-encode connection options they are space-separated key=value pairs.

This causes several issues:

• Only the first parameter is parsed

PGOPTIONS="--log_level=debug --search_path=custom" psql 'postgresql://...' -c "show search_path"
search_path   
-----------------
 "$user", public
(1 row)

• Common -c key=value syntax is not supported

PGOPTIONS="-c search_path=custom" psql 'postgresql://...' -c "show search_path"
search_path   
-----------------
 "$user", public
(1 row)

• When --search_path is first, following options are passed through

PGOPTIONS="--search_path=custom --work_mem=1234567" psql 'postgresql://...' -c "select name, setting from pg_settings where name in ('search_path','work_mem');"
    name     | setting 
-------------+---------
 search_path | custom
 work_mem    | 1234567
(2 rows)

PGOPTIONS='--search_path=custom -malformed' psql  'postgresql://...' -c "show search_path"
server closed the connection unexpectedly

Note

In this case, Supavisor repeatedly tries to reconnect and floods the logs with: [error] DbHandler: Error auth response ["SFATAL", "VFATAL", "C42601", "Minvalid command-line argument for server process: --search_path=custom", "HTry \"postgres --help\" for more information.", "Fpostgres.c", "L3931", "Rprocess_postgres_switches"]

Related issues

• Connection Pooler string does not honor options parameter with search_path #206
• Prepend application_name from client to application_name set by DbHandler only in session mode #343

What is the new behavior?

• Supports both --key=value and -c key=value forms.
• Ignores malformed tokens safely and logs a warning.
• Prevents unintended parameters from being forwarded to Postgres.
• Passes recognized option values as-is to Postgres, preserving quotes and escapes

Additional context

Integration tests for this behavior are included in #770

[v0idpwn]

Incorporated this in #858 too, thank you!