Generated compose leaves root-owned node_modules and .next mountpoints on Linux hosts #292

On a Linux host, the compose file seamless init --local writes (src/generators/docker/docker.ts) puts an anonymous volume over a path inside each bind-mounted source tree:

• api: ./api:/app plus /app/node_modules
• web: ./web:/app plus /app/node_modules
• web in the Next.js full-stack layout: also /app/.next
• auth (./auth:/app) and admin with --admin=source (./admin:/app) use the same /app/node_modules pattern

When that path does not exist in the host directory, Docker creates it as the mountpoint, owned by root. After docker compose up, a Linux user ends up with empty root-owned directories in their project. In a run on a Linux host (docker:29-dind, project owned by uid 1001) these were:

./api/node_modules
./web/node_modules
./web/.next        (Next.js layout)

They are empty, so rm -rf my-app still works, which is why this was left out of fells-code/seamless-templates#126. But anything run on the host that writes into them fails with EACCES until they are removed with sudo: npm install in api/ or web/ (for the editor's types, or to run the app outside Docker), or next build / next dev on the host for the Next.js layout. Docker Desktop on macOS maps ownership, so it does not show there.

Possible fix (not yet verified)

Create the mountpoint directories at scaffold time, as the user running init, so Docker mounts the volume over a directory that already exists and leaves its ownership alone. That needs a check on Linux that Docker does not chown an existing mountpoint, and that .gitignore already covers each path (all the starters ignore node_modules; check .next for the Next.js starter).

The quickstart check in #289 only asserts that the project can be removed, so it would not catch this. A follow-up assertion could run test -w on each mountpoint after docker compose up.