fix: generate projects from bundled templates only

[very-good-code-bot]

Summary

Changes the create command to always generate from the bundled template instead of fetching from the remote brick registry (brickhub.dev). This makes project generation deterministic, offline-first, and ensures users get exactly what we test and ship.

What Changed

• Removed the remote brick fetch fallback in _getGeneratorForTemplate()
• Removed the MasonGeneratorFromBrick typedef and _generatorFromBrick parameter from all create subcommands
• Updated all create subcommands to only use generatorFromBundle
• Simplified template resolution to always use template.bundle
• Updated tests to reflect bundle-only generation path

Why This Matters

Before: The CLI used a caret constraint (e.g., ^1.3.3) to fetch bricks from the registry, which resolved to the latest compatible published version. The bundled version was only a fallback for offline scenarios.

Consequences:

• Version mismatch: CLI bundles v1.3.3 but generates v1.4.0
• Non-deterministic output: Template publishes change results without CLI releases
• Untested paths: E2E tests validate latest published brick, not committed bundles
• Upstream risks: Template releases can silently change/break create

After: Always generate from template.bundle, making:

• ✅ Generated projects match the bundled template version
• ✅ Deterministic output (no surprise updates from registry)
• ✅ CLI is the single source of truth for templates
• ✅ Faster generation (no network dependency)
• ✅ Fully offline-capable

Template updates are now delivered only via CLI releases (via tool/generate_bundles.sh).

Testing

• Removed tests for remote brick fetching and fallback behavior
• Updated tests to verify generation uses the bundled template
• All existing create tests continue to pass with the simplified path

Closes #1625