Session transfer does not preserve preferences on HTTPS and double-encodes cookie JSON

Description

The session-transfer flow does not reliably preserve client preferences. There are two independent problems in the current implementation:

1. On HTTPS, the pad client stores preferences in prefs, but the transfer UI reads only prefsHttp and the receiver always writes prefsHttp.
2. The transfer UI reads the raw percent-encoded cookie value from document.cookie. Passing that value to Express res.cookie() encodes the percent signs again. On the destination, js-cookie decodes once, leaving percent-encoded JSON that JSON.parse() cannot parse.

This is present on develop at f2cf95e06cd613fd0a06bbcb755e044c1dbfe306:

• welcome.ts returns raw cookie wire text and reads only prefsHttp
• pad_cookie.ts selects prefs on HTTPS and parses the decoded value as JSON
• The receiver writes the submitted value with res.cookie() under prefsHttp
• The cookie documentation confirms the protocol-specific names

Steps to reproduce

1. Open a pad over HTTPS and change a client preference such as theme/font/chat visibility.
2. Create a session transfer from the settings dialog.
3. Redeem the code in a different browser/device.
4. Open a pad and inspect the transferred preferences.

The HTTPS source does not submit the prefs cookie. On HTTP, where prefsHttp exists, a typical JSON cookie such as %7B%22...%22%7D is submitted in encoded form and then encoded again when the destination cookie is written.

Actual behavior

Preferences are missing or unreadable after transfer; pad_cookie.ts falls back after its JSON.parse() failure.

Expected behavior

The destination should receive the same preferences for both HTTP and HTTPS deployments, encoded exactly once in the cookie format expected by js-cookie.

Possible direction

Transfer a decoded/validated preference object or JSON string rather than cookie wire bytes, select the source/destination cookie name according to the request protocol, and let one layer perform cookie encoding.

No plugins are required. I found this while benchmarking an automated code-review workflow and manually verified the current source and duplicate search before reporting it.