refactor(cli): route iii project init/generate-docker through scaffolder-core

Per Anthony's review on PR #1607 — fully accept the architectural pivot.
Template content (config.yaml, .gitignore, Dockerfile, docker-compose.yml)
no longer ships embedded in the engine binary; everything is fetched at
runtime from the canonical iii-hq/templates repo via scaffolder-core.

What changed:
- Deleted engine/src/cli/project/{scaffold.rs, docker.rs, project_ini.rs,
  templates/*}: ~150 lines of in-engine generation gone.
- mod.rs now uses scaffolder_core::IiiConfig + TemplateFetcher + copy_template
  for the bare flow ('bare' template) and fetches the docker template's
  Dockerfile + docker-compose.yml directly via fetch_file_bytes (skipping
  shared_files merge so we don't clobber the user's config.yaml on layered
  --docker / generate-docker invocations).
- .iii/project.ini is now persisted via scaffolder_core::telemetry::write_project_ini
  (the canonical writer) — engine no longer maintains its own. project_id is
  preserved across re-runs.
- .env is still generated in-engine (RabbitMQ password is a fresh UUID per
  invocation, and III_HOST_USER_ID needs the host's device_id at write time
  — both are runtime concerns, not template content).
- Added --template-dir flag to GenerateDockerArgs for parity with InitArgs.

Tests:
- engine/tests/fixtures/templates/ mirrors iii-hq/templates#2 so e2e tests
  don't depend on that PR landing for CI to pass. All e2e tests pass
  --template-dir pointing at the fixture.
- 11 e2e tests pass against the new dispatch path.
- Existing 101 bin + 23 cli_integration tests unchanged.

Blocker: end-user `iii project init myapp` (without --template-dir) will
fail until iii-hq/templates#2 lands. Documented in PR description.

Author: guibeira