fix(cable_install): pin firebase, and stop re-adding firestore.rules

[mattdrees]

Closes #12.

1. The pins

0.5.0 stopped vendoring the controller, and the three Firebase pins had been riding along with the vendored file. So an app following the new README from scratch got a registered controller whose import … from "firebase/app" resolved to nothing — the module throws on load. Loud, unlike #9, but broken at install.

cable_install now appends them to config/importmap.rb:

pin "firebase/app", to: "https://www.gstatic.com/firebasejs/12.0.0/firebase-app.js", preload: false
pin "firebase/auth", to: "https://www.gstatic.com/firebasejs/12.0.0/firebase-auth.js", preload: false
pin "firebase/firestore", to: "https://www.gstatic.com/firebasejs/12.0.0/firebase-firestore.js", preload: false

Still the app's file, not an engine pin, so the app keeps control of the Firebase SDK version — the issue's reason for leaving them app-side holds. Idempotent, and it says so plainly when there's no config/importmap.rb (esbuild apps). Listed in the README too, for anyone not using importmap.

2. The rules

--rules now, opt-in. I checked the duplication claim: cru-terraform-modules/applications/solid-gcp/firestore.rules.tftpl is byte-identical to the gem's template except ${collection} where the template hardcodes the default — so for any app on the default collection they really are the same file, and the app's copy is reference material that only looks deployable. Went with inverting rather than --skip-rules because re-running the generator is now the supported upgrade path and should be idempotent for the common case, which at CruGlobal is terraform owning the ruleset.

3. A comment that was wrong

While copying the dummy's pin comment I noticed it claims preload: false means "the cable client only loads them when a stream element is on the page." It doesn't: controllers/index.js imports the controller at boot, so the firebase modules load with it on every page of a cable app; preload: false only keeps them out of the modulepreload set. Comment corrected in both places rather than propagated.

Worth a follow-up if that lazy behavior is actually wanted: the controller would need a dynamic import() inside connect(). That's a real change to the connect path (and to emulator-connect ordering), so I left it alone here. It would also mean non-cable pages stop paying for the SDK.

Tests

Five added to the generator test — pins written, pins not duplicated on re-run, missing-importmap message, no rules by default, --rules writes the starter — and the two existing tests updated for the new default. Gem 125 runs / 320 assertions, dummy 13 runs, system-with-emulators 3 runs (1 credential-gated skip), all green.

Not done here

No version bump; entries under [Unreleased]. I'll cut v0.5.1 after this merges.

🤖 Generated with Claude Code