cross-repo-intelligence: --target-projects flag silently parses to zero targets; with raw-JSON args the worker crashes (0-byte log)

[junk151516]

Environment: v0.9.0, Windows amd64 (ui variant). Source project: Python/FastAPI + Svelte monorepo (~31k nodes, 928 intra-repo HTTP_CALLS edges). Target project: Python legacy monorepo (~13.5k nodes) whose REST API the source calls over HTTP — so real cross-repo matches should exist.

Repro 1 — flag form, silent no-op:

cli index_repository --repo-path <A> --mode cross-repo-intelligence --target-projects '["<project-B>"]'
# → {"status":"success","projects_scanned":0,"total_cross_edges":0,"elapsed_ms":2.9}
# Same result with --target-projects '["*"]'

The array flag value is apparently dropped: projects_scanned: 0 plus an instant "success". An unknown or unparseable target should be an explicit error — silent-zero results mislead LLM agents (same family as #1111).

Repro 2 — raw JSON args, worker crash (2/2):

echo '{"repo_path":"<A path>","mode":"cross-repo-intelligence","target_projects":["<project-B>"]}' | cli index_repository
# → {"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}
# Reproducible with ["*"] too. Worker log: 0 bytes (see my resource-guards issue).

So the flag form never reaches the matcher, and the JSON form reaches it and crashes. The source project's existing index survived intact in all attempts (verified via index_status).

Asks: fix array parsing in the flag form, error out on zero resolved targets instead of returning success, and include the culprit file in the crash hint.

[DeusData]

Thanks for separating the flag-path no-op from the raw-JSON crash. This is a high-priority 0.9.1-rc correctness and containment bug. The RED cases should independently prove that --target-projects preserves a JSON array, zero resolved targets fail explicitly rather than returning success, and equivalent raw-JSON input cannot crash the worker. The existing project index must remain intact in every failure case; the 0-byte worker-log problem is tracked in #1132.