Package layout: internal/, cmd/, tools and docker/ #35

Parent

Spec: #33 (Baseline release). Section numbers refer to its Implementation Decisions.

What to build

The public surface is exactly upstream's nine lib/ packages; everything that is not library code moves to where Go convention puts it, so a user installs the two commands with go install and never sees developer tooling in a public package. Spec section 2; ADR-0009; ticket #17.

Acceptance criteria

• lib/assets (with its generator) becomes internal/assets; the seven helpers Exec, ExecLine, UseNode, S, EscapeGoString, ReadString, TestEnvs move from lib/utils to internal/devutil; the remote-launch manager becomes cmd/wand-manager; the pre-fetch command becomes cmd/wand-fetch-browser; the setup, lint, ci-test, simple-check and shell tools and the image build script become internal/tools/<name>; the Dockerfiles and fonts config move to docker/.
• Every go:generate directive, Dockerfile and build script references the new paths; generators stay beside the packages they generate.
• go install ./cmd/... produces exactly wand-manager and wand-fetch-browser.
• go doc ./lib/utils lists none of the seven helpers; nothing under lib/ or the root imports internal/devutil except generators.
• No subdirectory remains under lib/utils; lib/assets does not exist; internal/ sits at the module root.
• go generate ./... (a browser is still needed for the protocol at this point) leaves a clean tree; build, vet and the full suite pass as before.

Blocked by

• Snapshot import and module rename #34 (Snapshot import and module rename)