Replace pako with fflate for smaller bundle size and faster compression

[thewtex]

Summary

Replace the pako dependency with fflate for zlib-wrapped deflate compression used in TIFF tile encoding. This yields a significantly smaller bundle footprint and improved compression performance with no change in output format or compatibility.

Changes

• package.json — Swapped pako (^2.1.0) for fflate (^0.8.2) in dependencies; removed @types/pako from devDependencies (fflate ships built-in TypeScript types)
• src/tiff-writer.ts — Replaced import { deflate } from "pako" with import { zlibSync } from "fflate" and updated the synchronous fallback call site (deflate(data, { level }) → zlibSync(data, { level }))
• src/write.ts — Updated JSDoc comment referencing the fallback path
• test/tiff-writer.test.ts — Replaced import("pako").inflate with import("fflate").unzlibSync in round-trip decompression tests

Why

Factor	pako	fflate
Minified size (compress-only)	~45 kB	~5 kB (9x smaller)
Tree-shakeable	No (CJS)	Yes (ESM)
TypeScript types	External @types/pako	Built-in
Compression speed	Baseline	~50% faster
Decompression speed	Baseline	2–16x faster

Both libraries produce standards-compliant zlib-wrapped deflate (RFC 1950), which is what TIFF compression code 8 requires. Data compressed by fflate is fully decompressible by pako, zlib, and geotiff.js — and vice versa.

Implementation Details

• Only one production call site existed: the synchronous fallback in compressDeflate() at src/tiff-writer.ts:325. The primary async path uses the native CompressionStream API and is unchanged.
• pako's deflate() produces zlib-wrapped output by default → maps directly to fflate's zlibSync().
• The only option used was { level }, which fflate supports with the same semantics.
• Compressed output is not byte-identical between libraries (different valid representations of the same data), but all round-trip and geotiff.js integration tests pass.
• All 213 tests pass, TypeScript typecheck is clean.