Fix Form.parse to decode + as space

[carpentry-agent]

Summary

Form.parse used URI.unescape directly, which only handles %XX percent-encoding. Per the application/x-www-form-urlencoded specification (RFC 1738 / HTML5), spaces are encoded as + in form submissions. This meant any form value containing spaces (submitted via a standard HTML form) would silently retain the + characters instead of decoding them.

Changes

• Added a private form-unescape helper in the Form module that first replaces + with space (via split/join), then calls URI.unescape for percent-decoding. This ordering ensures %2B (literal +) is decoded correctly.
• Updated Form.parse to use form-unescape instead of URI.unescape for both keys and values.
• Added tests covering: single +, multiple +, %2B as literal +, and + in keys.

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[carpentry-reviewer]

Build & Tests

CI: Passing (macOS + Ubuntu). No local Carp compiler on Pi; relying on CI.

Findings

1. form-unescape logic — correct. The split-by-+-then-join-with-space-then-percent-decode ordering is correct. This ensures %2B (literal +) survives the +→space step and is decoded properly in the URI.unescape pass. Edge cases:

• hello+world → "hello world" ✓
• %2B → "+" ✓
• a+%2B+b → "a + b" ✓
• lone + → " " ✓

2. Tests — thorough. Four new tests cover: single +, multiple +, %2B as literal +, and + in keys. All the cases that matter.

3. No issues found. Clean, minimal change. The function is correctly marked private and hidden. The doc string update accurately describes the new behavior. No other code paths are affected.

Verdict: merge

Correct fix for a real spec-compliance bug, well-tested, CI green.