G-126 progress: build subcommand finished upstream (streaming writer)

Upstream punkzip 572d893 (v2.3.0, 130/130) turns the January build
scaffolding into a working streaming recursive zip writer per user
decision (finish rather than remove - the shipped tool should be useful
from the start). Progress records the design (per-member streaming,
sorted deterministic entries, dir members, zip64 refusal) plus the
second zig-0.16 trap found en route (OpenFileOptions.allow_directory
defaults true, breaking file-vs-dir probes). Remaining-for-acceptance
list now starts at vendoring.

Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com

goals/G-126-punkzip-accelerator.md

@@ -202,10 +202,26 @@ working tree; one now exists.
   parity suite can compare it directly. Member comments deliberately deferred to a v2.
   (The user separately committed upstream hwzip 2.4 C source under `reference/` for
   sync comparison - cb2a731.)
-- Remaining for acceptance: `build` subcommand finish-or-remove decision; vendor into
-  `src/tools/punkzip/` with provenance (upstream commit id), re-vendor procedure and
-  licence records; make.tcl tool build step (zig OPTIONAL - absence reported, not
-  fatal; test gate keys on exit code, not clean stderr - the zip suite's negative
-  tests print EOCD warnings while passing); punk::zip accelerator detection + fast
-  path behind the G-124 floor; parity suite in `src/tests/modules/punk/zip/`;
-  recorded benchmark (speedup + entry count where it becomes material).
+- 2026-07-27 `build` subcommand FINISHED upstream (user decision: finish rather than
+  remove - the tool punkshell ships should be useful from the start; commit 572d893,
+  punkzip v2.3.0, suite 130/130): `build [-m <method>] [-c <header>] <zipfile>
+  <paths...>` is now a streaming recursive zip writer - zipper.add_entry streams
+  LFH + data per member (memory bounded by largest member, mirrors zip_write's
+  method dispatch and store-fallback contract), finalize_zipfile writes a real
+  central directory + EOCD with the -c header as archive comment (zip64 sizes and
+  >65535 members refused), directory members stored with trailing '/' and
+  EXT_ATTR_DIR, entries sorted lexicographically for DETERMINISTIC archives
+  regardless of directory enumeration order. Verified: repo src tree (45 members
+  incl. binary fixtures) built and extracted recursively byte-identical by both
+  Windows bsdtar and punkzip extract -d. Second 0.16 trap recorded en route:
+  `OpenFileOptions.allow_directory` defaults TRUE, so file-open probes succeed on
+  directories - the scanner's file-vs-dir probe silently recorded directories as
+  empty files until opens passed `.allow_directory = false` (guard also added to
+  list/extract file opens).
+- Remaining for acceptance: vendor into `src/tools/punkzip/` with provenance
+  (upstream commit id), re-vendor procedure and licence records; make.tcl tool build
+  step (zig OPTIONAL - absence reported, not fatal; test gate keys on exit code, not
+  clean stderr - the zip suite's negative tests print EOCD warnings while passing);
+  punk::zip accelerator detection + fast path behind the G-124 floor; parity suite in
+  `src/tests/modules/punk/zip/`; recorded benchmark (speedup + entry count where it
+  becomes material).