Fix strict-mode false positives for unset flags with default values

[hexonal]

Fixes #1874

Problem

EZA_STRICT=true (or --strict) rejects even a bare eza invocation with no relevant flags at all — strict_check_long_flags uses matches.contains_id(flag) to check whether the user passed a flag that only makes sense with --long, but clap's contains_id is true once a flag has been parsed and assigned any value, including its unset/default value, not just when the user actually supplied it on the command line.

Fix

Switch to matches.value_source(flag) == Some(ValueSource::CommandLine), which only matches flags the user actually supplied. This works uniformly for both boolean (SetTrue) and value-taking flags in the checked list (get_flag would panic on the value-taking ones like time/loc, which is why contains_id was presumably used originally).

Testing

• Manually verified the exact false-positive from the issue is gone: EZA_STRICT=true eza (bare invocation) now runs cleanly.
• Verified true positives still correctly error: -b/--binary alone, --git alone, --level 2 alone (all under --strict), and that -l -b together (long + binary, which is meaningful) still succeeds.
• Added two regression tests calling Mode::strict_check_long_flags directly: one asserting a bare invocation is Ok(()), one asserting --binary alone still errors. Confirmed the first test actually catches the regression by temporarily reverting just the source fix and re-running — it fails as expected, then passes again with the fix restored.
• Full existing options:: test suite (124 tests) passes, no regressions.
• cargo fmt --check clean on the changed file.
• cargo clippy --release -- -D warnings fails on an unrelated pre-existing issue in build.rs (a useless_borrows_in_formatting lint) — confirmed this exists identically on a clean, unmodified upstream/main checkout, so it's a local clippy-version mismatch unrelated to this change, not something introduced here.

[hexonal]

The Check Nix Flake (trycmd, x86_64-linux) failure is unrelated to this change — it's a stale --version output snapshot (v0.23.4 expected vs v0.23.5 actual, out of sync since the recent version bump commit). Confirmed this is repo-wide right now, not specific to this PR: it's also failing on an unrelated open PR (#1879, hyperlink flag fix) with the identical diff.