Add directory-entry listing and existence helpers to file discovery

[kojiwakayama]

Summary

Extracts the standalone file-discovery infrastructure from the multi-agent staging branch (#2354), per the agreed split (PR A): listDiscoveryDirectoryEntries (immediate, non-recursive directory listing) and discoveryFileExists (path existence), both fsAdapter-aware with Node fallback.

Purely additive — no behavior changes to existing discovery. First of the extraction series; delegates: support (PR B) follows separately.

Testing

• deno test --no-check --allow-all src/discovery/file-discovery.test.ts — 3/3 pass
• deno test --no-check --allow-all src/discovery — full suite green

Type of Change

• New feature (non-breaking, additive infrastructure)
• Test update

[ariskemper]

Ran a structured review pass (quality / correctness / security) over this slice. Clean extraction overall — the fsAdapter/Node dual-path mirrors the existing findFilesByExtension conventions and the helpers are exactly the right primitive for the stack. A few findings, all minor:

1. Redundant Boolean() coercion on the fsAdapter path (file-discovery.ts, listDiscoveryDirectoryEntries): DirEntry.isFile/isDirectory are declared boolean in src/platform/adapters/base.ts:161, so Boolean(entry.isFile) is a no-op — and worse, if an adapter ever wrongly exposed these as methods, Boolean(fn) would coerce to true and silently misclassify every entry as both file and directory. Using the properties directly (as findFilesByExtension does at line 26) keeps a type error surfaced instead of masked.

2. Node fallback path is untested: all three tests inject a fake fsAdapter, so the readdirSync/Dirent branch (where isFile()/isDirectory() are method calls, not properties) never runs under test. That branch is exactly where the contract differs, so one real-tempdir test without an adapter would lock it in.

3. (Optional) The fsAdapter-vs-Node branching + exists-check + swallow-errors scaffolding is now repeated a third time in this file. If a fourth helper appears, extracting a shared readDiscoveryDirEntries(dir, context) core would pay for itself — not blocking for this PR.

Nothing security-relevant in this slice. LGTM after #1.

[kojiwakayama]

Addressed the sensible review items in 99699d3d: removed the Boolean() coercion so adapter contract drift does not get masked, and added a real tempdir test for the Node readdirSync fallback path. Focused discovery test and the pre-push suite both passed.