Stack detection covers only the Node ecosystem — every other stack starts on an empty job site

Problem

facility init promises to detect the repository's package manager and checks, but
packages/cli/src/detect.mjs only knows the Node ecosystem:

• Package manager: pnpm-lock.yaml → yarn.lock → package-lock.json → package.json → "none" (detect.mjs:26-35). There is no probe for composer.json, pyproject.toml, go.mod, Cargo.toml, pom.xml/build.gradle, or Gemfile.
• Checks: derived exclusively from package.json scripts (typecheck/lint/test/build), so a non-Node repo gets an empty check list.
• migrationDirs knows only migrations, supabase/migrations, db/migrations, prisma/migrations — no database/migrations (Laravel), no Alembic/Django layouts.
• The generated workflow for a non-Node repo carries a stub: # facility: no Node toolchain detected. Add your language setup steps (init.mjs:54).

Why it matters

The method doc names the dominant failure mode Facility exists to prevent: "the
environment can't run anything, so verification is impossible, so the agent hedges …
The fix is not a better prompt. It is a better job site." Today, every PHP, Python,
Go, Java, Ruby, and Rust repository begins its Facility life on exactly that empty
job site: no provision proposal, no checks, a comment where the toolchain should be.
The delivery contract ("run the configured checks; a partial deliverable is a
failure") has nothing to bind against, and the first /builder run produces the
hedging behavior the method predicts.

The current behavior also fails silently from the adopter's point of view: init
completes, the questions get asked, and the gap only surfaces at the first paid run
— the same late-surfacing shape as #28.

Proposal

A deterministic ecosystem adapter table in detect.mjs, the same pattern as
detectDeploymentProvider:

Scope boundaries, to keep it reviewable:

• Proposals, not assumptions — everything stays a default the init prompts
  show for confirmation, exactly as the Node defaults do today. Repos that declare
  their commands keep them; detection only fills silence.
• One coherent change to detect.mjs + its fixture-repo tests (the CLI test
  pattern already runs the real installer against temporary repositories).
• No new dependencies (CLI stays zero-runtime-dependency).
• Multi-ecosystem repos (e.g. PHP backend + Node frontend) record all matches and
  propose the union of checks, mirroring how deployment providers accumulate.

I'm happy to implement this behind the issue-first agreement in CONTRIBUTING.md,
starting with the composer.json adapter (PHP is where I can validate against real
repositories with real provisioning — databases, migrations, coverage drivers —
rather than toy fixtures) and adding the others in the same PR if the shape is
agreed, or in follow-ups if you'd rather keep the first diff minimal.

Read CONTRIBUTING.md for the issue-first agreement, then inspect packages/cli/src/detect.mjs and init.mjs, along with the existing fixture-repo CLI tests. Start with the proposed composer.json adapter and verify the real installer detects it, preserves declared commands, proposes provisioning and checks, and includes the relevant migration directory without adding dependencies.