Add Cloudflare application bootstrap skill

[irvinebroque]

Add an application setup workflow that connects framework configuration, bindings, secrets, initial data, and generated types through the first verified local request. Existing apps use supported automatic configuration or their current setup; new apps use an appropriate C3 template. The skill preserves existing frameworks and services, distinguishes local simulation from remote bindings, and keeps deployment within the requested scope.

Register the skill in the README and route app setup from the Cloudflare umbrella skill.

Validation: skill-creator quick_validate.py passed; git diff --check passed. Read current Cloudflare developer documentation for automatic configuration, automatic provisioning, C3, local development, secrets, build variables, D1 migrations, Durable Object class exports, and generated types, and checked that it supports the guidance. This is an instruction-only change; no application was scaffolded or deployed.

Documentation caveat: automatic provisioning is currently beta, and automatic configuration depends on the installed Wrangler version. The skill retrieves current supported behavior rather than embedding product lists or version-specific schemas.

[kale-stew]

The resource, secrets, and "verify the first real request" sections are good agent guidance: classifying values by consumer (build, browser, runtime), not removing existing resource IDs, distinguishing simulated from remote bindings, and checking the state change rather than server start. None of that is elsewhere in the repo. The setup entry points need rework:

1. New apps: use cf init, not C3. "New app: Use C3" contradicts #189 ("Do not route framework setup through C3") and the cf default proposed in #226. Per Deploy your first Worker, cf init creates the project; framework apps follow the framework's own setup and the Workers framework guide.

2. Existing app without configuration: use cf. Same point as on #120 and #189: cf runs automatic configuration for supported frameworks when there is no cloudflare.config.ts. Keep wrangler setup only for a project that already uses Wrangler or when the user asks.

3. Provisioning behavior differs by CLI. "Deployment can provision remote resources and write identifiers back to config" is true for Wrangler. cf deploy provisions missing resources but does not write identifiers back to cloudflare.config.ts (Develop, build, and deploy), so agents should record them. Similarly, wrangler types applies to Wrangler projects; cloudflare.config.ts is typed.

4. Consolidate with #189. Both PRs rewrite the "Start a Worker or framework project" row and will conflict. Choosing one skill for setup routing, with the other linking to it, avoids two competing entry points.

5. Rebase and switch to markdown routes (#211).