fix(curl): interpret @file for --data, --data-binary, --data-urlencode (#239)

* fix(curl): interpret @file for --data, --data-binary, --data-urlencode

Real curl reads file contents when -d / --data / --data-binary /
--data-urlencode are passed @filename. just-bash's curl previously sent
the literal "@filename" string as the HTTP body, which broke
POST/PUT-from-file workflows (e.g. curl --data-binary @payload.json).

- -d / --data @file : read file, strip CR + LF (matches curl docs).
- --data-binary @file: read file verbatim, newlines preserved.
- --data-urlencode @file and name@file: read file, URL-encode contents,
  optionally prefix name=.
- --data-raw keeps its documented "no @ interpretation" semantics.

Adds 15 tests covering each variant, mixing with inline payloads, and
the missing-file error path.

* review: encode `=` in @file urlencode + clarify scope of -d last-wins

Copilot review on #239:

1. resolveUrlencodeFiles used encodeFormData() for `@file` and `name@file`,
   which splits on the first `=` to separate a name/value pair. For raw
   file contents that contain `=` bytes (e.g. "a=b&c") this produced
   "a=b%26c" instead of the correct "a%3Db%26c". Switch to
   encodeURIComponent so the whole file body is treated as one value;
   `=` is percent-encoded like any other reserved character. Two
   regression tests added (`=` in @file, `=` in name@file).

2. Reword the doc comments on parse.ts:applyDataArg and types.ts:dataFile.
   The previous text claimed last-write-wins "matches real curl"; real
   curl actually combines repeated -d/--data flags with `&`. Just-bash's
   pre-existing inline behavior is last-wins; this PR preserves that
   scope and only fixes the @file gap.