feat(deploy): provision client-mode Endpoint(image=...) resources during flash deploy

[justinwlin]

Problem

Fixes #365 · Internal: CON-1230

An Endpoint declared in client mode (image=..., no decorated functions) produced a build manifest with an empty resources map. flash deploy uploaded the artifact, created the app and environment, printed ✓ deployed to production, and exited 0 — provisioning nothing. flash env get production then showed no resources. run flash deploy --env production, pointing the user back at the command that had just run.

Fix

The build now discovers top-level client-mode Endpoint(image=...) objects during scanning and registers each as a function-less manifest entry marked client_mode: true. Deployment config — imageName, gpuIds/instanceIds, workers, scaler, env, volumes, datacenter locations — comes from the Endpoint's own _build_resource_config(), the same object first-run() provisioning uses.

From there the existing deploy path (reconcile_and_provision_resources → create_resource_from_manifest → ResourceManager.get_or_deploy_resource) provisions them like any other resource and persists endpoint URLs into the state manifest. So flash env get lists them, and re-deploys reuse the same endpoint unless config changed.

The first commit on this branch (f36fa48) shipped an honest "no deployable resources" message instead. That short-circuit remains, but now only fires for projects declaring neither decorated resources nor client-mode endpoints.

Verified

Check	Result
pytest tests/unit/cli --no-cov	587 passed
pytest tests/unit --no-cov	2575 passed, 3 failed (pre-existing)
ruff check + ruff format, touched files	clean
Offline end-to-end chain	provisionable objects produced

The 3 failures are pre-existing

test_load_balancer_sls_stub.py ×2 and test_regressions.py REG008 reproduce identically with these changes stashed — order-dependent pollution on the base commit, not introduced here.

Offline end-to-end chain

Real RuntimeScanner → ManifestBuilder.build() → create_resource_from_manifest() over a client-only project (GPU vllm-openai + CPU whisper) yields provisionable LiveServerless/CpuLiveServerless objects carrying the user image, GPU/CPU config, workers, and env. Verified with FLASH_IS_LIVE_PROVISIONING unset (concrete class names) and =false (normalized to Endpoint, still provisionable).

What changed

build_utils/scanner.py — RuntimeScanner collects top-level Endpoint instances with image= set and id unset (those attach to existing endpoints) into scanner.client_endpoints during module import. Re-exports (from defs import ep in a second file) are tolerated when the image matches; the same name with a different image fails the build with a "defined in multiple files" error.

build_utils/manifest.py — ManifestBuilder._add_client_endpoints registers each client endpoint into resources with functions: [], client_mode: true, and config extracted by re-importing the source module and calling _build_resource_config() (same _extract_config_properties path as decorated resources). resource_type records the concrete class only when the deploy-time provisioner can rebuild it; otherwise it falls back to "Endpoint", which create_resource_from_manifest resolves to GPU/CPU via gpuIds. Name collisions with decorated resources raise.

cli/commands/deploy.py — the empty-resources message is reworded to "no deployable resources found; nothing was deployed" and only triggers when the manifest has no resources at all.

Four supporting changes

• cli/utils/deployment.py — _FLASH_SOURCE_FINGERPRINT env injection skips client_mode entries, so code-only deploys don't trigger pointless rolling updates of external-service endpoints. Reconciliation is otherwise unchanged, which is what keeps re-deploys idempotent (state-manifest compare + get_or_deploy_resource reuse).
• build_utils/handler_generator.py — skips client_mode resources; no functions means no handler to generate.
• cli/commands/preview.py — local preview skips client_mode resources; they run user-supplied images and are provisioned remotely.
• runtime/resource_provisioner.py — supported class list is now a module-level PROVISIONABLE_RESOURCE_TYPES. Behavior unchanged.

Live testing

2026-08-25, real Runpod account. Client-mode-only app:

Endpoint(name="con370-live-1248", image="runpod/serverless-hello-world:0.4.1",
         gpu=GpuGroup.AMPERE_16, workers=(0, 1), idle_timeout=60)

• flash deploy created app con370-live + production env and provisioned and printed the endpoint: con370-live-1248 https://api.runpod.ai/v2/4kuwiutqisjt2f/runsync. On main the same app yields empty resources and a false success.
• GET /v1/endpoints/4kuwiutqisjt2f → workersMin: 0, workersMax: 1, idleTimeout: 60, gpuTypeIds: [A4000, A4500, 4000 Ada, 2000 Ada] (the AMPERE_16 pool), flashboot on. Deployed config matches the request.
• flash env get production lists the endpoint. On main it printed no resources.

Out of scope

• workersStandby: 1 on the live endpoint is expected here and addressed in fix(serverless): default workersStandby to workersMin so workers=(0, N) scales to zero #372.
• Idempotency is covered by the mocked tests (state-manifest carry) rather than a second live deploy; the single live deploy above was the missing piece.