`--repo` without `[project.scripts]` exits with a traceback

Summary

A --repo pointing at a project whose pyproject.toml has no [project.scripts] raises RuntimeError out of resolve_repo_meta with a full traceback, rather than the one-line diagnostic every other failure in the script prints. --entry cannot rescue it either: the derived-value lookup runs before the override is applied.

A nonexistent --repo path is handled cleanly, so this is specific to the no-scripts case.

Reproduction

printf '[project]\nname = "x"\n' > "$SB/bare/pyproject.toml"

run use-local --repo "$SB/bare" --cli cursor --no-preflight

run use-local --repo "$SB/bare" --entry libtmux-mcp --cli cursor --no-preflight

Expected

A one-line message and a non-zero exit, matching how the script reports every other bad input. --entry should let a caller name the entry point when it cannot be derived.

Actual

  File ".../scripts/mcp_swap.py", line 732, in resolve_repo_meta
    raise RuntimeError(msg)
RuntimeError: <sandbox>/bare/pyproject.toml has no [project.scripts] — cannot derive entry

The repo's own tests assert "Traceback" not in captured.err for CLI-boundary failures elsewhere, so this path is inconsistent with the intended contract.

References

• resolve_repo_meta at v0.1.0a20

Start in scripts/mcp_swap.py at resolve_repo_meta around lines 710-735, then trace how --entry is applied and how other CLI-boundary failures are reported. Reproduce with a pyproject.toml lacking [project.scripts], using both --repo and --entry. Done means both cases emit a one-line diagnostic without "Traceback" and exit non-zero.