Fix stale files and .env.local handling in the basic-ts template

[JulienLavocat]

Description of Changes

Running spacetime init --template basic-ts and then following the printed "Next steps" gives a project with several problems. This fixes the ones that live in the template itself.

• The client ignores .env.local. spacetime init writes SPACETIMEDB_HOST and SPACETIMEDB_DB_NAME to .env.local, but src/main.ts only reads process.env and nothing loads the file. npm run dev therefore always connects to ws://localhost:3000 / basic-ts, even for a project initialised against Maincloud. It works under spacetime dev only because the CLI injects both variables into the client process.

  src/main.ts now calls process.loadEnvFile?.('.env.local') inside a try. Variables already set in the environment take precedence, so spacetime dev behaves as before. process.loadEnvFile exists from Node 20.12 and 21.7. On older versions the call is skipped and the client still uses the localhost defaults, as it does today, so this does not fix the problem there but does not raise the documented Node 18+ requirement either. A missing .env.local is ignored.

• The checked-in bindings are stale. src/module_bindings was generated by CLI 2.0.0 and lacks the procedures export. Regenerated with pnpm generate; the diff is the version header and that export.

• basic-ts is skipped by pnpm generate. It had no generate script, unlike react-ts and most other templates. Added the same script they use.

• A stale lockfile ships with every new project. spacetimedb/pnpm-lock.yaml pins spacetimedb to 1.* (1.9.0), while package.json depends on the current SDK. Template files are embedded from the git-tracked file list, so it was copied into each generated project. Removed.

Not addressed here:

• Bugfix: spacetime init --template react-ts creates a broken .env.local #5941 fixes the database name mismatch between .env.local and spacetime.local.json, which is in init.rs. With both PRs, a freshly initialised basic-ts client should connect to the database that spacetime publish creates; I have not tested the combination.
• templates/nodejs-ts reads the same two variables the same way and has the same .env.local problem.
• templates/nuxt-ts/spacetimedb/pnpm-lock.yaml is the same kind of leftover.
• Most other TypeScript templates still ship 2.0.0 bindings (angular-ts, browser-ts, bun-ts, deno-ts, nextjs-ts, nodejs-ts, nuxt-ts, react-ts, remix-ts, solid-ts, svelte-ts, tanstack-ts, vue-ts). CI has no check that the TypeScript template bindings are up to date.

API and ABI breaking changes

None.

Rollback safety impact

n/a

Expected complexity level and risk

1. Template-only change; no CLI or server code is touched.

Testing

• pnpm -F spacetimedb build, then pnpm generate in templates/basic-ts; the resulting diff is only the version header and the procedures export. Without the SDK build first, generate fails with Could not resolve 'spacetimedb/server'.
• pnpm -F ./templates/basic-ts build, tsc --noEmit and eslint templates/basic-ts/src/main.ts in the workspace.
• Built spacetimedb-cli from this branch and ran spacetime init --template basic-ts --non-interactive into an empty directory: no spacetimedb/pnpm-lock.yaml, bindings header reads 2.11.0. spacetime build, tsc --noEmit in both packages, and npm run build pass. spacetimedb@2.11.* is not on npm yet, so the generated project was pointed at this branch's crates/bindings-typescript build for the install.
• npm start in that project with WebSocket stubbed to print the URL it dials:
  • .env.local present: wss://maincloud.spacetimedb.com/v1/database/e2e-app/subscribe (on master: ws://localhost:3000/v1/database/basic-ts/subscribe)
  • SPACETIMEDB_HOST / SPACETIMEDB_DB_NAME set in the environment: those values win over the file
  • no .env.local: ws://localhost:3000/v1/database/basic-ts/subscribe, no error
  • process.loadEnvFile set to undefined (simulating an older Node): same defaults, no error
• Reviewer: spacetime dev in a fresh basic-ts project against a local server. I did not run this, nor the test_template_basic_ts smoketest, nor a real Node 18 or 20 runtime (only Node 24 was available).