[feat] init/scaffold CLI to generate the background & shader registry files

[the-simian]

Problem

#26 defines the consumer-curated registry pattern, but its v1 is manual: the consumer hand-creates the registry files (kaleidoscope.backgrounds.ts, kaleidoscope.shaders.ts) by copy-pasting from the README, and wires the config plugin into their app config themselves. That works, and a person or a coding agent can follow the README, but it is boilerplate the library can generate.

Proposed solution

Ship a scaffolding command with the library (a bin entry, e.g. npx react-native-webrtc-kaleidoscope init) that writes the canonical files into the consumer's project, pre-populated with the library's default presets. It is a template writer in disguise; it holds almost no logic.

What it does:

• Create the two registry files at the convention path the prebuild plugin reads, pre-filled with the shipped presets imported by their package subpath specifiers (require('react-native-webrtc-kaleidoscope/backgrounds/<name>.webp'), and the shader equivalents with their default-uniform JSON).
• Write each file with a header comment carrying the plugin-wiring instructions (the same copy-paste the README gives), so the instruction travels with the file and is found by whoever (or whatever) edits the config next.
• For the app config: if it is app.json, add the plugin entry automatically (safe JSON edit, idempotent). If it is app.config.js / .ts, do not edit it; print the one-line plugins entry and state that it must come after expo-build-properties.

Model: shadcn-style scaffolding, with one deliberate difference. shadcn vendors a whole component implementation into your repo; here the CLI vendors only the declaration (the registry files the consumer owns and curates), while the engine, the plugin, and the asset bytes stay in the package. The consumer then adds or removes registry entries to grow or shrink their bundle.

Constraints and cautions

• Idempotent: re-running must not clobber a consumer's curated registry. Skip existing files, or merge additively; never overwrite curation.
• Never AST-edit app.config.js / .ts, and never rewrite the app entry component. Additive file writes plus printed instructions only. Rationale carried from [feat] consumer-curated, tree-shakeable shader-preset registry + single kaleidoscope() command (prebuild mods) — v1 manual setup #26: the plugin has an ordering constraint a machine cannot place correctly inside an arbitrary config, and arbitrary TS configs are not safely round-trippable.
• Automatic config editing is limited to app.json.

Dependencies and sequencing

Depends on #26: the registry file format and the convention path must be stable before a generator templates them. Build this after the manual pattern ships and settles. This is pure developer-experience sugar; the library is fully usable without it by following the README.

Scope

Fits: a packaged dev tool that writes the same files the README documents. Out of scope: editing arbitrary JS/TS configs, mutating app code, anything at app runtime.