feat: ship raw binaries (not zips) in npm process-plugin packages

[dsherret]

Summary

dprint now supports referencing a raw executable from a process plugin's per-platform npm sub-package, so the helper no longer needs to wrap the binary in a .zip. Two changes:

1. Raw binaries in sub-packages. CreateDprintOrgNpmPackagesOptions.platforms[].zipFilePath is renamed to binaryPath (breaking — only one PR was using it). The file at binaryPath is copied verbatim into the sub-package under its basename, marked executable (mode 0o755) on Unix, and referenced from the main package's plugin.json as npm:<sub-package>@<version>/<basename> instead of .../plugin.zip.

2. name and version at the top of package.json. Generated package.json files now order keys as: name, version, then caller-supplied packageJsonExtra (any fields that collide with managed keys are dropped), then managed platform/dependency fields (os/cpu/libc for sub-packages, optionalDependencies for the main).

Caveats

• Cross-OS publishing. Running npm pack/publish from Windows packs files without the Unix executable bit, because the host filesystem can't carry that mode. CI on Ubuntu is fine; for local bootstrap publishes, use a Unix host.
• Existing PluginFileBuilder API is unchanged — the zipFilePath/zipUrl parameter names are now slightly misleading (they accept any file) but the behavior is general and renaming would break create_plugin_file.ts style callers that still ship zips via GitHub releases.

Test plan

• deno test -P — 7/7 pass, including a new test pinning the name/version-at-top contract and updated assertions for the new reference URL format.
• deno check / dprint check clean.
• After release, dprint-plugin-exec's create_npm_packages.ts will be updated to extract the platform zips and pass the binaries through to the helper.