`rtk ls -d` drops explicitly-named NOISE_DIRS arguments when mixed with other paths

#3466 fixed rtk ls -d .hidden_dir for a single explicitly-named argument. The fix does not hold once a non-filtered argument is present in the same invocation: the filtered argument disappears again, with exit code 0 and no marker.

Reproduced on rtk 0.45.0 (Homebrew, latest release v0.45.0), macOS 26.5 (arm64). Outputs verbatim.

Reproduction

mkdir -p /tmp/repro/{src,docs,.venv,node_modules}
cd /tmp/repro

$ ls -d src .venv
.venv
src

$ rtk ls -d src .venv
src/

.venv is gone. Same for any NOISE_DIRS name:

$ rtk ls -d src node_modules
src/

$ rtk ls -d docs src .venv
docs/
src/

Why #3466's fix does not cover this

The filtered argument survives only when every argument would be filtered — that path falls back to passthrough:

$ rtk ls -d .venv                 # single filtered arg  → passthrough
drwxr-xr-x@ 2 user staff 64 Aug 18 09:52 .venv

$ rtk ls -d .venv node_modules    # all args filtered    → passthrough
drwxr-xr-x@ 2 user staff 64 Aug 18 09:52 .venv
drwxr-xr-x@ 2 user staff 64 Aug 18 09:52 node_modules

$ rtk ls -d src .venv             # one arg survives     → filter applies
src/

So the single-argument case from #3466 passes while the mixed case still fails. A test that only covers rtk ls -d <one-filtered-name> will not catch this.

-a confirms the mechanism is the NOISE_DIRS filter at src/cmds/system/ls.rs:266 (src/core/constants.rs:1-27):

$ rtk ls -d -a src .venv
.venv/
src/

Why this is worse than the no-argument case

-d <path> means "report on exactly these paths." The user named .venv explicitly and rtk answered as if it did not exist.

Exit code is 0, and rtk does propagate genuine failures — so a caller cannot distinguish the two:

$ rtk ls -d src .venv        ; echo "exit=$?"
src/
exit=0

$ rtk ls -d src nonexistent  ; echo "exit=$?"
src/
exit=1

For an LLM agent this reads as a definitive ".venv does not exist," which is the failure mode #3466 was filed about.

Relationship to existing issues

• #3466 (closed) — same command shape, single argument only. This is the remaining gap.
• #3434 (open) — the no-argument rtk ls case. Its evidence shows rtk ls dist working, which suggests explicitly-named paths are safe. They are not, once mixed.
• #3386 (open) — filters.ignore_dirs config keys never read; about configurability, not about dropping named arguments.
• #2857 (open) — also multi-argument ls, but about losing the per-directory path: headers. Orthogonal: that one mislabels entries that are printed; this one omits an operand entirely.
• #3207 (open) — attributes empty ls output to LC_TIME. Not the cause here: this reproduces identically under LC_ALL=C, LC_ALL=C LC_TIME=C, and LC_ALL=en_US.UTF-8.

Suggested direction (untested)

Treat explicitly-named path arguments as exempt from NOISE_DIRS filtering — the filter exists to compress discovery (bare ls, tree), and an explicit path is not discovery. If suppression is still wanted there, #3434's suggestion applies: emit a one-line notice naming what was hidden and how to show it, so the output cannot be read as absence.

Start at the NOISE_DIRS filtering in src/cmds/system/ls.rs:266 and the definitions in src/core/constants.rs:1-27, then reproduce the mixed explicit-path commands shown in the issue. Add regression coverage for filtered and non-filtered operands together; done means explicitly named noise directories remain visible with the correct exit status while discovery filtering still works.