feat(cli): surface project environment in config and doctor

[nibzard]

Summary

Users had no way to tell from the CLI which project (environment) their API key is scoped to, or whether it's production. The API exposes this via GET /v1/projects (name, slug, isProduction), so this PR surfaces it in the two places users ask "where am I pointed?":

• steel doctor — new "Project" check after auth:

  Auth
    ✓ API key valid
  Project
    ✓ Project "Default project" (default) — development
  

  Fetched concurrently with the existing auth probe (no added latency) and silently skipped on any error, so an informational check can never degrade doctor's overall status. JSON mode carries {project_id, name, slug, is_production} in the check detail.

• steel config — prints project: Default project (default) and environment: development. Best-effort with a 2s timeout and graceful skip (offline, local mode, or no key), so the command stays instant and usable offline.

Implementation notes

• New src/api/projects.rs owns the /projects binding, response parsing, and current-project resolution: a single project wins outright; among several, a sole isDefault wins; ambiguity resolves to nothing rather than a guess.
• src/api/generated.rs is untouched — the long-term home for this binding is tagging GET /projects with x-steel-cli in the API's OpenAPI spec and regenerating.
• Local mode skips the lookup entirely (no cloud project exists).

Testing

• 17 new tests (parsing, resolution, env label, wiremock round-trip, doctor check construction), full suite green.
• Verified live against api.steel.dev: steel config, steel doctor --preflight (text + --json).

🤖 Generated with Claude Code