Variables.ps1 serializer does not escape quotes in variable values — corrupts the config file

variables.ps1 serializer does not escape quotes in variable values — corrupts the config file

**Version:** Reproduced on 2026.2.2 and 2026.1.6 (Windows, IIS-hosted and self-hosted)

**Summary**
Creating a plain (non-vault) variable whose value contains a quote character serializes an unescaped value into `.universal\variables.ps1`, making the file syntactically invalid. PowerShell Universal keeps serving variables from the database, so nothing visibly breaks — until the next configuration reload or service restart, when the file fails to parse ("Invalid configuration: ...variables.ps1") and variables fail to load.

**Steps to reproduce**
1. Create a variable via the Admin UI or REST API:
- Name: `QuoteTest`
- Value: `conn"str'test;pwd=fake"x` (any value containing a single quote reproduces it)
2. Open `.universal\variables.ps1`.

**Actual result**
The serialized line is written with the embedded quote unescaped:

New-PSUVariable -Name "QuoteTest" -Value 'conn"str'test;pwd=fake"x'

The embedded `'` is not doubled, so the string terminates early and the file no longer parses (`TerminatorExpectedAtEndOfString`). Verify with:

$errs = $null
[System.Management.Automation.Language.Parser]::ParseInput(
    (Get-Content -Raw .\.universal\variables.ps1), [ref]$null, [ref]$errs) | Out-Null
$errs

**Expected result**
Values are escaped for single-quoted PowerShell literals (`'` doubled to `''`), keeping `variables.ps1` valid for any value.

**Impact / why this is nasty**
- The corruption is **silent**: runtime serves variables from the DB, so the broken file sits armed until a restart or config sync, then every variable in the file is at risk of failing to load at once.
- One bad value poisons quote-pairing for **every subsequent line**, so the parse errors point at unrelated variables many lines below the actual culprit, which makes diagnosis genuinely difficult.
- Realistic trigger: pasting a SQL connection string whose password contains a quote — which is exactly how we hit it in production.

**Workaround**
Store quote-bearing values as vault-backed secrets (no value is serialized into variables.ps1), or hand-repair the file line with proper `''` escaping.