docs(cloud): document projects as the canonical Management API resource

[claudespice]

Summary

The Management API resource previously called an app is now called a project. /v1/projects is the canonical path and /v1/apps remains served as a permanently supported legacy alias, marked deprecated in the published OpenAPI specification. The Management API pages still documented only the legacy paths.

This updates the two hand-written Management API pages to the canonical paths and adds a section explaining the relationship, including the two details that actually break a naive migration:

• The list envelope differs. GET /v1/projects returns results under a projects key; GET /v1/apps keeps its original apps key. Everything else — response shapes, field names — is identical.
• OAuth scope names did not change. They are still apps:read, apps:write, and apps:delete, because they are embedded in already-issued tokens. The scope table now describes them in project terms while keeping the literal names, and a note says so explicitly.

The Spice CLI, Terraform provider, and SDKs continue to call the legacy paths, so the page states they are unaffected.

Pages updated

• cloud/api/management/README.md — new Projects and apps section and an intro hint; canonical paths in all curl examples; scope descriptions and rate-limit wording updated; endpoint list labels renamed.
• cloud/api/management/dedicated-clusters.md — canonical POST /v1/projects and PUT /v1/projects/{projectId}, and project terminology throughout.

Verification

• Live-ness evidence: the canonical path is live in production. The published specification at api.spice.ai/openapi.json lists all seven /v1/projects* paths, carries all seven /v1/apps* paths with deprecated: true, and its own description states the rename. Unauthenticated GET /v1/projects returns 401 (route exists and reaches the auth layer) while a nonexistent path returns 404.
• Response envelope keys (projects vs apps) read directly from the published spec's 200 response schemas, not inferred.
• Internal links resolve; the #projects-and-apps and README.md#create-a-deployment anchors both match real headings. No new pages, so no SUMMARY.md change.
• GitBook {% hint %} syntax used, not ::: admonitions.
• No private-repo references in branch name, commits, title, body, or content.

Deliberately out of scope

• Two pre-existing broken links in cloud/api/management/README.md (../../../portal/profile/personal-access-tokens.md, which needs ../../, and ../../../support/support.md). Both are already on trunk and both are covered by the open sitewide link-repair PR fix(docs): repair broken and cross-space docs links sitewide #127, which touches this same file — left alone to avoid a conflict.
• The wider portal terminology rename. Pages under cloud/portal/ still say "Apps", matching neither the portal UI nor this page. That is a much larger editorial sweep across many pages plus navigation entries and deep links, and it deserves its own PR rather than riding along here. The new section is written so a reader landing on either term is not confused in the meantime.

The generated Management API reference under Management APIs comes from the GitBook OpenAPI block, so its endpoint list tracks the published spec automatically and needed no edit.