test: add adversarial / fuzz input tests for parsers and path/name handling

[goanpeca]

The SDK parses attacker-influenceable or environment-influenceable strings: B2 wire responses, file names, response headers, range specs, and SSE-C key material. Hand-written tests cover the happy path; fuzzing hostile inputs is cheap insurance against crashes, hangs, and injection/traversal.

Proposal: reuse fast-check (see the property-based issue) to drive adversarial inputs, asserting the SDK either handles the input safely or throws a typed, contained error, and never crashes, hangs, or escapes a boundary.

Targets:

• decodeFileName and the X-Bz-Info-* header parsing path: unicode, embedded control chars, percent-encoding edge cases, very long names, partial/invalid escapes.
• Range parsing (parseRangeHeader and the download range math): malformed, negative, inverted, overflowing, and out-of-bounds ranges resolve to a defined outcome (400/416/throw), never a hang or NaN slice.
• Numeric inputs (sizes, part numbers, counts): negative, zero, overflow, and non-integer values reject deterministically.
• SSE-C key material: wrong lengths, non-base64, and oversized inputs reject without leaking key bytes into messages.
• The B2Simulator request parser: malformed JSON bodies and missing or duplicate headers produce a B2-shaped error, not an unhandled throw.

Acceptance criteria:

• A fuzz/adversarial test module that runs in the standard suite with a fixed seed.
• Each target asserts a contained outcome (typed error or safe value); any crash/hang/traversal found is fixed or tracked.

Related: complements the property-based issue (invariants) and the SSRF protection already provided by UrlGuard.