create-blocks-app starter templates ship a greet()-referencing test that goes stale once the sample API is replaced

[hfurkanbozkurt]

Problem

Bench run 28701776910 (PR #132) surfaced that cells scaffolded with create-blocks-app wasted effort on stale starter test files:

• file-gallery / bare (lowest-scoring cell, composite 78.6): the starter test still referenced the old greet() method after the sample API was replaced, producing an immediate test failure that required manual investigation.
• email-digest and oidc-dsql-notes: cells churned rewriting stale test files (.ts → .mts migrations, spawn-based rewrites) that existed solely because of the starter template's shape.

The underlying issue: the starter test exercises the sample greet() endpoint by name, so any scaffold where the developer (or agent) removes or renames the sample API immediately inherits a failing test — before any real implementation work has started.

Request

Make starter test files minimal and resilient — or decouple them from the sample greet() API — so that replacing the sample API in a freshly-scaffolded app does not immediately leave a failing test. Options include:

• A trivially-passing placeholder test (e.g. it('should be implemented', () => {})) with a comment pointing to the real API once it exists.
• A test that imports nothing from the sample endpoint and only asserts app-level setup (e.g. env vars present, server starts).
• A TODO stub that is skipped by default (it.skip).

Evidence: agent-bench run 28701776910 / PR #132

[ikenyal]

I separated this into two concerns: the sample greet assertion is a template-content decision, while the Setup readiness loop should not depend on that sample API. I plan to address only the second concern.

The backend, bare, demo, and auth-cognito templates currently poll greet before tests start. I will replace that probe with a request to /.blocks-sandbox/config.json and check response.ok, so an unrelated process on port 3000 is not treated as ready.

The dev server begins listening only after startup initialization and client generation complete, making this a neutral readiness signal. The existing greet assertions will remain unchanged; any decision on replacing those sample tests stays separate.

[ikenyal]

Implemented the readiness portion in #198. It changes the backend, bare, demo, and auth-cognito template setup loops to wait for the Blocks configuration endpoint, while keeping the existing sample greet assertions unchanged. The broader question of whether those sample assertions should be replaced remains separate from this focused fix.