Compress 1 MB of English below 270,000 bytes, self-extracting

Download the submitted .js file and grep it for the literal substrings "require(", "import ", "import(", and "import{" anywhere in the file, including comments and strings; any hit is an automatic reject. Confirm the file's own byte size against the claimed score and the target/record thresholds. Then run it in a clean subprocess with no arguments, no network, and a 300-second timeout, capturing stdout, and compare its sha256 to the corpus's published hash:
      node file.js > out.bin   # in an isolated subprocess, network disabled
      sha256sum out.bin
      cat /data/corpus-1mb.txt.sha256
    The two hashes must match exactly, and out.bin must be exactly 1,000,000 bytes with no trailing newline or extra output. A dishonest or broken submission typically embeds the corpus close to verbatim (e.g. base64 of the raw text, which is easy to get running but nowhere near the target size), or has an off-by-one or bit-ordering bug in its arithmetic coder that produces output differing from the corpus only in a handful of bytes or trailing whitespace, which still fails since the check is an exact sha256 match, not an approximate diff.

Background. This is a self-extracting-archive challenge in the spirit of the Hutter Prize (which pays out for shrinking enwik8/enwik9, on the premise that predicting text well is closely tied to understanding it). Here the corpus is smaller and fixed: exactly 1,000,000 bytes of real English prose from a Project Gutenberg book, the same bytes forever. You write one JavaScript file that embeds both a decompressor and the compressed representation of that corpus, and running it regenerates the corpus exactly. Reference points for plain-text English compression ratios (compressed size / original size): gzip -9 (DEFLATE) usually lands around 36-38%; xz/LZMA around 28-30%; PPMd (as in 7-Zip's PPMd mode) around 24-26%; context-mixing compressors in the paq8/cmix family (the state of the art, and the engines behind most Hutter Prize entries) around 16-20%, though they are typically slow and code-heavy. Your score is the whole artifact's size, so a fancy context-mixing decoder that costs 40 KB of JavaScript code can lose to a simpler order-2 arithmetic coder that costs 2 KB, even if the fancy one's embedded payload is smaller. The sweet spot is usually a compact arithmetic (range) coder plus a small adaptive context model, all in a few kilobytes of code, carrying an embedded compressed bitstream sized close to the ratios above.

Artifact format. Submit a single JavaScript file, at most 1,000,000 bytes. It must run standalone: node your-file.js with no arguments, no network, no environment beyond a clean PATH, and no packages. When it finishes, whatever it wrote to stdout must be exactly the 1,000,000-byte corpus, byte for byte (checked via sha256). No trailing newline, no extra output, no partial output.

Hard rule: no require and no import, of anything, including Node builtins like "zlib" or "fs". This is enforced with a plain static text scan of your source before it is ever executed, checking for the literal substrings "require(", "import ", "import(", and "import{" anywhere in the file, including inside comments or strings. Avoid those substrings entirely, anywhere in your file, not just in real code. The point of the rule is that your file has to be its own decompressor; you cannot lean on Node's zlib or any other library.

Execution limits. Your file is run in an isolated subprocess with a 300-second (5 minute) timeout and a 1,100,000-byte cap on captured stdout (going over either fails the run). Five minutes is generous: even a byte-at-a-time adaptive arithmetic decoder with a nontrivial context model should decode 1,000,000 bytes well within that window in plain JavaScript, but avoid accidentally quadratic string concatenation (build output in a preallocated Buffer/Uint8Array and write it once, not with repeated string += over a million characters).

Scoring. Score = your artifact's byte size. Direction is min (smaller is better). Target (mission "solved"): under 270,000 bytes, i.e. below roughly 27% of the corpus, competitive with PPMd. Record: under 200,000 bytes, i.e. below 20%, competitive with context-mixing compressors.

Corpus. Served at /data/corpus-1mb.txt (exactly 1,000,000 bytes: the first 1,000,000 bytes of a public-domain Project Gutenberg text, fixed forever, so you can develop and tune against it offline). Its sha256 is served alongside at /data/corpus-1mb.txt.sha256 as a hex string, so you can confirm your local copy matches before building against it.

Strategy. The natural approach: (1) offline, on your own machine, build a compressor: an adaptive context model (order-1, order-2, or order-3 byte contexts are a good starting point) feeding an arithmetic/range coder, and run it over the corpus to produce a compressed bitstream; (2) embed that bitstream in your JS file (as a binary string, a base64 blob, or a packed array literal -- base64 is usually a good size/complexity tradeoff); (3) ship the matching decoder (which must be adaptive in exactly the same way, updating its model from previously decoded bytes as it goes, mirroring what the encoder did) so that node your-file.js writes the corpus back out. Because the corpus never changes, you are free to hand-tune your context model or your initial frequency tables specifically for this text (or for English prose in general) as long as the whole file, tables included, stays small. A model that starts from reasonable generic English byte/order-1 statistics and adapts as it decodes typically beats one that starts from nothing, without costing much code. Since the decompressor code itself counts against your score, prefer a small number of well-tuned context orders with simple blending over an elaborate multi-model mixer, unless the mixer earns back more bytes from the payload than it costs in code.

Common pitfalls: accidentally embedding the corpus close to verbatim (e.g. plain base64 of the raw text) is easy to get working but only reaches about 133% of the original size, nowhere near target; any literal occurrence of "require(" or "import " anywhere in the file (even in a comment) gets you rejected before your code ever runs, so grep your own file for those substrings before submitting; writing output with console.log or string concatenation can silently corrupt binary bytes or add a trailing newline, use process.stdout.write on a Buffer/Uint8Array of exactly the right length instead; and an off-by-one or bit-ordering bug in your arithmetic coder tends to produce output that is close to correct but not byte-identical, which still fails, since equality is exact (sha256), not approximate.