fix(project): report no default entry when a path component is a file

[e54-bot]

Summary

• A directory containing a regular file named src (and no main.opy) was reported EntryUnreadable because the src/main.opy probe failed ENOTDIR; it now reports DefaultEntryNotFound, identical to an empty directory — and targetNotFound through the provider, matching the issue's parity case.
• A direct entry path through a file (file.opy/child.opy) keeps EntryUnreadable, per the issue's separate-question clause; the existing entry_inside_a_file test already pins that reason.

Fixes #497.

Test plan

• cargo test -p opy-rs --lib project — 19/19, incl. new file_named_src_in_a_directory_is_default_entry_not_found (asserts only the shared outcome; comment states verified platform)
• CLI repro: opy-cli check on d (file src) and e (empty) prints the identical default-entry error
• cargo test --workspace --all-targets, cargo fmt, cargo clippy -D warnings clean

[e54-bot]

Verified locally — the fix is correct and both acceptance criteria hold.

AC check

• (a) Parity case: exercised end-to-end via opy-cli check. d (dir containing a regular file src) and e (empty dir) now print the identical cannot find a default OPY entry result. DefaultEntryNotFound → is_entry_not_found() == true → targetNotFound for Directory targets (crates/opy-provider/src/main.rs:1056-1060), matching e.
• (b) The new test asserts only the shared outcome (is_entry_not_found() + DefaultEntryNotFound), which holds under both arms now handled — Unix NotADirectory and Windows NotFound — and its comment states it was verified on macOS.

Edge cases exercised (scratch dirs + opy-cli check):

• dir with file src AND a valid main.opy → loads main.opy; first candidate wins and the probe order is unchanged.
• src/ dir containing main.opy → normal case loads, unaffected.
• src symlink → regular file → DefaultEntryNotFound (fs::metadata follows links → ENOTDIR arm).
• src dangling symlink → DefaultEntryNotFound (NotFound arm).
• main.opy as a directory → DefaultEntryNotFound via the pre-existing 'present but not a regular file' arm.
• file.opy/child.opy direct entry → still EntryUnreadable (cannot read entry: Not a directory (os error 20)), preserving the issue's separate-question clause.

Windows reasoning: fs::metadata through a file component maps to NotFound there, and ERROR_DIRECTORY — if any Windows API surfaces it — maps to NotADirectory; both kinds are handled, so the d/e parity holds on Windows either way. MSRV 1.85 covers ErrorKind::NotADirectory (stable since 1.83).

Validation: cargo test -p opy-rs --lib project — 19/19 pass, incl. file_named_src_in_a_directory_is_default_entry_not_found. cargo fmt --all --check, cargo clippy -p opy-rs --lib -- -D warnings, and git diff --check clean.

Non-blocking notes:

1. The neighboring entry_inside_a_file_is_not_classified_as_missing comment (project.rs:266-267) still claims canonicalization fails ENOTDIR 'on every platform' — per this issue's own findings Windows reports a not-found error for a path through a file, so that claim is stale. Worth correcting opportunistically.
2. The stated reason for the direct-entry case (EntryUnreadable / entryUnreadable) is Unix-accurate; on Windows the same input likely classifies EntryNotFound / entryNotFound, so it is not literally consistent across platforms. Distinguishing it there would require component-wise probing — fine to leave as the issue's 'separate question', but a comment or follow-up reference would keep the divergence explicit.