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

[tony]

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