[ar-api] Honor CLI project creation credentials (VID-33)

[digaobarbosa]

Description

project create advertised an API key override, but used the environment or default workspace key instead. A user targeting another workspace could fail during authentication or lookup before the project was created.

The command now uses the explicit key when supplied, otherwise the key stored for the selected workspace. The same key reaches authentication, workspace lookup, and project creation.

Project types, the creation request, and the id/name/type output remain the same.

Validation

• python -m unittest tests.cli.test_project_handler: 16 passed. Two tests invoke the public CLI with isolated HTTP responses and assert the key on auth POST, workspace GET, and project POST for explicit and stored-key cases. They also check payload and JSON output for object detection and Action Recognition.
• /kiss: removed one redundant mocked Action Recognition creation test; the real CLI test retains its type, payload, and result assertions.
• make check_code_quality, test-file Ruff format/check, and git diff --check: passed.
• Live staging E2E evidence: both credential paths passed on exact head dd32ce87e22222eec319ababbc7e7f6f75c4220e; independent GET and CLI get/list confirmed private Action Recognition projects, followed by exact-fixture Trash cleanup and active GET 404.
• Exact-head CI: 15 checks passed, including Ubuntu and Windows Python 3.10–3.13 builds.

Runtime scope

The CLI does not expose the create POST's numeric status; E2E confirmed CLI exit 0 and subsequent authenticated GET 200. Testing used disposable private staging projects. No production writes, uploads, training, deployment, or package publication occurred.

[digaobarbosa]

E2E verification on exact PR head dd32ce87e22222eec319ababbc7e7f6f75c4220e passed against staging https://api.roboflow.one in model-evaluation-workspace (October 1, 2026). The installed CLI imported the editable SDK from the isolated VID-42 worktree. No mocks were used.

1. An explicit valid --api-key over a conflicting invalid ROBOFLOW_API_KEY created private Action Recognition project vid42-explicit-20261001173420-fcfa6f (CLI exit 0; JSON id/name/type). Authenticated GET returned 200 with matching fields; CLI project get and project list found it.
2. With no environment key, the selected workspace's stored key over a distinct invalid default-workspace key created vid42-selected-20261001173426-66a3fd with the same CLI and read checks.

Both exact fixtures were deleted through the public CLI Trash path. Each active GET then returned 404, and Trash listed the matching slug and project ID (iS7l6HRAwofuGz84CG1r, fsxwEN7Fzf8myntG5WB5). The public CLI did not expose the create POST's numeric status. No production writes, uploads, or training were performed. Local project-handler tests: 16/16; required quality checks passed; exact-head CI: 15/15 successful.