…ring ng add (#3714)

* feat(schematics): generate .firebaserc and Firestore starter files during ng add

ng add asks the user to pick a Firebase project but never records the
choice, so every later firebase-tools command has no default project.
It also leaves firebase.json empty and creates no security rules, so a
Firestore-selected workspace cannot deploy rules at all.

Now, after the project prompt, the schematic records the selection in
.firebaserc (merging into an existing file rather than replacing it).
When Firestore is selected it also generates firestore.rules and
firestore.indexes.json — the same test-mode starter files that
'firebase init firestore' produces, with a warning that the rules
expire in 30 days — and wires the firestore section into firebase.json.
Existing rules files are left untouched.

The new files go through the schematic Tree; firebase.json stays on the
real filesystem because firebase-tools reads and rewrites it during the
same run, and its firestore section is added only after those rewrites.

* fix(schematics): move firestore starter files after init, widen error handling

Tyler's review on #3714: createFirestoreStarterFiles staged the Tree
before the DataConnect init calls, using a pre-init firebase.json
snapshot. If a future init call ever added a firestore section
mid-run, the stale snapshot would miss it and stage starter files on
top of files firebase-tools already wrote to disk — the same
Tree/disk collision the .firebaserc write hit earlier in this PR.
Moved the call to run after init with a fresh re-read, and documented
the more immediate invariant this enforces: it must run before
addFirestoreToFirebaseJson, which is what adds the firestore section
on a normal run.

Also widened addFirestoreToFirebaseJson's try/catch to cover the
firebase.json mutation and write, not just the read — a write
failure (disk full, permissions) previously crashed with a raw Node
error instead of the warn-and-continue the read path already gets.

* fix(schematics): warn instead of crashing when the post-init firebase.json read fails

The re-read added for the firestore starter files was unguarded, so a
firebase.json that firebase-tools left unreadable would abort the whole
ng add. Before the starter files moved after the init calls, this same
failure degraded gracefully — the files were already staged, and
addFirestoreToFirebaseJson warned and let setup finish. Restore that:
warn and continue. createFirestoreStarterFiles independently checks the
disk for each file it would create, so a missing snapshot costs the
firestore-section check, not the collision safety it also relies on.

Trimmed the surrounding comments to the two constraints a future edit
could silently break — read after init, and run before
addFirestoreToFirebaseJson — and moved the rationale here.

The reason the read sits after the init calls at all: staging against a
stale pre-init snapshot risks the Tree/disk collision the .firebaserc
write hit earlier in this PR, where a Tree-staged file collides at
commit time with one firebase-tools already wrote to disk and aborts the
run. No init call adds a firestore section today, so that specific path
is defensive against a future one.

#3717)

* fix(schematics): warn when ng add setup runs with no features selected

Pressing Enter without toggling any checkbox at the features prompt
silently exited with the CLI's stock "Nothing to be done." message,
giving no indication that Space selects a feature. Print a warning
explaining the checkbox controls and inviting a retry.

* refactor(schematics): derive the empty-features warning from the prompt message

The empty-features warning duplicated the checkbox prompt's message as a
second string literal, so a reworded prompt would leave the warning
pointing at text the user never sees. Export the message as a shared
constant and reference it in both places, matching the shared-constant
pattern used for the firebase-tools version message in 59c8a2f.

… v20.1.0 release