CLI: curate --sql-file and up --data-root answer bad path input with a traceback and exit 1

[chiruu12]

What happens

Two commands still answer bad path input with a traceback and exit 1. Measured on ccaa8ad,
same harness as #124:

curate --sql-file <a directory>    exit=1  IsADirectoryError: [Errno 21] Is a directory: '/tmp/probe/adir'
up --data-root <a file>            exit=1  NotADirectoryError: [Errno 20] Not a directory: '/tmp/probe/afile/runtime/dags'

Every other path flag on those commands prints one line and exits 2.

curate --sql-file

_command_curate (cli.py:788) reads the file inside a try that catches
(ValueError, FileNotFoundError):

sql = arguments.sql if arguments.sql is not None else arguments.sql_file.read_text()

read_text() on a directory raises IsADirectoryError, which subclasses OSError and not
FileNotFoundError, so it walks straight past the handler at cli.py:799.

Note this is the same class boundary #102 called out, seen from the other side. There the
fix was to keep raising FileNotFoundError so existing handlers keep working. Here the
exception comes from pathlib rather than from our code, so the handler is what has to
move.

up --data-root

A --data-root that is a regular file reaches render_bundle and fails inside mkdir
(_bundle.py:876):

for directory in (dags_dir, logs_dir, user_dir):
    directory.mkdir(parents=True, exist_ok=True)

The default bundle dir is <data-root>/runtime, so a file data root makes every one of
those three mkdir calls raise NotADirectoryError. _command_up catches
FileNotFoundError and (ComposeError, TimeoutError), neither of which covers it.

Nothing has been rendered or started when this happens, so it is bad input, exit 2, by the
same reasoning as #84, #90 and #95.

Definition of done

1. curate --sql-file pointed at a directory prints one line prefixed curate: and exits
   2, with no traceback.
2. up --data-root pointed at a regular file prints one line prefixed up: and exits 2,
   with no traceback, before anything is rendered.
3. Tests cover both, in tests/test_runtime_cli.py beside the existing exit-code cases.

Two things to get right

• Do not widen either handler to bare OSError. That would fold a genuine mid-run
  filesystem failure into "bad input" and exit 2. up in particular has a deliberate exit 1
  path that must survive. CLI: hflow serve answers bad launch input with a traceback and exit 1; ServerSettings accepts a non-int port #124 hit the same trap with RuntimeError and answered it with a
  narrower type rather than a wider catch.
• Check the data root before rendering, not by catching mkdir. Catching the mkdir
  cannot tell a bad --data-root apart from a genuinely unwritable bundle dir, and the
  second is not exit 2. _command_serve in CLI: hflow serve answers bad launch input with a traceback and exit 1; ServerSettings accepts a non-int port #124 does this check up front against
  is_bucket_url, which is the shape to copy.

Pattern to copy

_command_up already wraps RuntimeConfig(...) in its own try/except ValueError -> return 2
(#84), and #95 added a separate except FileNotFoundError block rather than widening an
existing tuple.

Validation

uv sync --locked --all-extras
uv run ruff check --fix
uv run ruff format
uv run ty check
uv run pytest -q

Notes

Found by sweeping every command and path flag with a directory where a file is expected and
a file where a directory is expected. Those two were the only survivors; everything else
already answers with one line and exit 2.

I am happy to do this one and will wait to be assigned first.

[kstonekuan]

Accepted, and yours. Both reproduce on 3bbfc28, same errno and same exit codes you measured.

One coupling to know about before you write the up half. You point at _command_serve as the shape to copy, which is right, but the is_bucket_url check you would be copying has an open question on it: #143 made a missing data root exit 2 as well as one that is a regular file, and whether the missing case should be refused is with @kstonekuan. Nothing creates the data root eagerly, so serve on a fresh clone hits it.

Your up case is a regular file, which is bad input under any reading, so start there and it is unaffected. Just do not extend the same check to a missing --data-root for up until that lands, otherwise the two commands could end up disagreeing.

Your two "get this right" notes are both correct and are the reason this is scoped well: no bare except OSError, and check before rendering rather than catching the mkdir.

One open PR at a time, so sequence this with #144.

[kstonekuan]

Closing the loop for @chiruu12: the serve question you worked around is settled, and it went your way. 7409433 narrows serve to refuse only a data root that exists and is not a directory. A missing root serves an empty workspace again.

Your carve-out in #147 was therefore right, and test_up_still_accepts_a_data_root_that_is_not_there_yet is now permanent rather than provisional. serve has the matching test beside it, so the two commands are pinned to the same answer.

The deciding fact was the one you can only get by looking: nothing creates the data root eagerly, so on a fresh install ./data does not exist until something ingests, and the server is already built to render that state rather than refuse it.