fix(showcase): drop bin/showcase build cache prune (out of scope for shared daemon)

`docker builder prune` operates on the entire Docker daemon, not on a
specific project's images. Reaping cache that's older than 24h would
also reap unrelated projects' cache that a teammate happens to share
the daemon with -- a colleague rebuilding a sibling Node project the
next day would face an unnecessary cold-cache build.

BuildKit doesn't expose a filter that's scoped to a project's cache
entries (only `until=<time>`, `type=<cachetype>`, `label=<k>=<v>` --
and labels can't be applied to cache entries from inside a Dockerfile).

Drop the prune. The lockfile-pinned `npm ci` change in the prior commit
is the actual root-cause fix and is enough on its own -- every rebuild
now hits a stable cache layer instead of redoing a 1.1 GB `npm install`
from scratch. Per-developer manual housekeeping (`docker builder prune
--filter "until=168h"`) remains the right escape hatch for accumulated
orphans.

Author: AlemTuzlak

showcase/bin/showcase

@@ -54,13 +54,6 @@ cmd_build() {
   trap restore_symlinks EXIT
   stage_shared
   $COMPOSE_CMD build "$@"
-  # Reclaim BuildKit cache layers left behind by interrupted builds. WSL2's
-  # docker_data.vhdx grows monotonically and never shrinks until `wsl
-  # --shutdown` + `Optimize-VHD`, so dangling cache from a build crashed
-  # mid-stream (e.g. by host OOM) accumulates and can balloon the VHDX into
-  # the hundreds of GB on Windows. 24h window keeps the warm cache for
-  # day-of work while reaping older orphans.
-  docker builder prune --filter "until=24h" -f >/dev/null 2>&1 || true
 }
 
 cmd_ps() {