server-core-worker: master-image-builder passes a streamx tar-fs Pack into dockerode.buildImage uncast

[tada5hi]

Found while auditing #1862. Nothing is broken today — this is a latent break with an identified trigger.

What

apps/server-core-worker/src/app/components/master-image-builder/handlers/execute/module.ts:129-131

const pack = tar.pack(imageFilePath);          // tar-fs, imported at :24
const stream = await this.docker.buildImage(pack, { t: imageTag, platform: 'linux/amd64' });

tar-fs@3.1.3 returns a streamx Pack, not a node:stream.Readable. Verified at runtime:

tar-fs version: 3.1.3
pack ctor: Pack
instanceof node Readable: false
isPaused / unpipe / wrap: undefined undefined undefined

dockerode's buildImage declares its first parameter as NodeJS.ReadableStream, which requires exactly those three absent members. So this assignment is unsound in the same way that #1861 had to paper over twice in container-pack.ts — except here it is uncast and uncommented, and it compiles.

Why it compiles

@types/tar-fs@2.0.4 models tar-fs 2.x, whose inner tar-stream resolves to DefinitelyTyped rather than to tar-stream's own bundled declarations. --traceResolution on the real tsconfig.build.json shows both type identities live in one program: tar-stream/index.d.ts@3.2.1 for direct imports, and @types/tar-stream/index.d.ts@3.1.4 via @types/tar-fs.

That split is held in place by nx, which the lockfile shows pinning tar-stream to exactly 2.2.0 and thereby occupying the root slot with an untyped 2.x copy.

Trigger

Any of:

• tar-stream getting hoisted to the root
• tar-fs shipping its own types (as tar-stream just did in 3.2.1)
• @types/tar-fs being updated to model tar-fs 3.x

Symptom would be a build failure in a file nobody edited, reading TS2345 ... Type 'Pack' is missing the following properties from type 'ReadableStream': isPaused, unpipe, wrap.

Coverage gap

No spec covers this handler. apps/server-core-worker/test/unit/ has 7 spec files; the master-image ones cover the synchronizer, not the builder. By contrast the equivalent path in container-pack.ts is covered end-to-end by test/unit/docker/pack.spec.ts, which was confirmed to genuinely assert (mutating its expected file size makes it exit 1).

Suggested handling

Do not add a speculative cast — the file compiles and works, and an as unknown as against a green build is unreviewable. Options, roughly in order of value:

1. A spec covering master-image-builder's execute handler, mirroring docker/pack.spec.ts. That converts a future silent break into a test failure and closes the real gap.
2. A two-line comment at :129 recording that tar-fs returns a streamx Pack and that @types/tar-fs@2.0.4 models 2.x, so the assignment is unsound-but-working.
3. Revisit when @types/tar-fs or tar-fs moves — see fix(deps): bump the minorandpatch group with 8 updates #1862 for why hub is currently declining tar-stream 3.2.1 rather than adapting to it.

[tada5hi]

Clarifying what this does and does not wait on, since #1865 now tracks the adjacent tar-stream work.

The test half needs nothing from upstream and should not wait. The real gap here is that no spec covers master-image-builder's execute handler, while the equivalent putArchive path in container-pack.ts is covered end-to-end by test/unit/docker/pack.spec.ts (verified to genuinely assert — mutating its expected file size makes it exit 1). A spec mirroring that one turns a future silent break into a test failure, and can be written today.

The typing half is not unblocked by the PRs tracked in #1865. streamx#125/#126 and tar-stream#181 are all declaration fixes. This issue needs streamx to actually implement isPaused, unpipe and wrap — real API surface. Only unpipe has open PRs (streamx#64, streamx#119, draft); isPaused and wrap have none. The alternative is dockerode narrowing buildImage/putArchive to the members docker-modem actually uses.

So: cross-linked with #1865 because the surviving putArchive cast there is this same unsoundness, but not blocked by it.