Eight components declared `"autoload": {"psr-4": {"WordPress\\<Name>\\":
""}}` but used WordPress file naming (`class-zipencoder.php`, not
`ZipEncoder.php`). PSR-4's CamelCase-to-filename rule never resolves
those classes, so a standalone `composer require wp-php-toolkit/zip`
lets `require vendor/autoload.php` succeed but leaves
`WordPress\Zip\ZipEncoder` and friends unautoloadable. The bug was
masked in the monorepo because the root `composer.json` uses a classmap
that picks the files up anyway.

Smoke-tested against the just-published v0.7.1 confirmed the regression:
`class_exists('WordPress\\Zip\\ZipEncoder')` returns `false` after
`composer require wp-php-toolkit/zip:^0.7`. Same shape for
`WordPress\Git\GitFilesystem` and the other affected packages.

Switching each to classmap (matching what BlockParser, HTML, ByteStream,
DataLiberation, Encoding, XML, Polyfill, Blueprints already do) makes
the per-component autoload work for downstream consumers in any layout.

Affected: CLI, Filesystem, Git, HttpClient, HttpServer, Markdown, Merge,
Zip.

`composer test` is at parity with trunk (1 pre-existing failure, 0
errors).