feat: 22 - fingerprint command

[joefrost01]

What problem are you trying to solve?

dtoo fingerprint existed but did not fully match specs/22-fingerprint-command.md behavior. Specifically, output used the full input path instead of filename-only, and IO/cloud error handling was too generic for the expected standalone command UX.

What does this PR change?

Completes the standalone fingerprint command behavior by:

• preserving 8KB chunked SHA256 hashing,
• printing sha256:{hex} {filename} (filename only),
• mapping file-not-found and permission-denied errors explicitly,
• improving cloud credential error messaging,
• adding focused fingerprint command tests.

Does this change align with DESIGN.md?

Yes.

• Command output remains stdout-only for successful fingerprint results.
• Errors flow through DtooError and continue to use exit code 1 for runtime failures.
• No query-pipeline ordering changes; this is standalone subcommand behavior.
• No licensing tier changes.

What alternatives did you consider?

1. Keep existing output with full path and document the difference. Rejected because spec 22 requires filename-only output for sha256sum familiarity.
2. Rebuild fingerprint command in main.rs directly. Rejected in favor of keeping logic encapsulated in src/fingerprint.rs.
3. Chosen: keep existing hashing implementation and refine output/error semantics plus tests.

Does this PR contain multiple unrelated changes?

No. All changes are directly related to standalone fingerprint command behavior.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: feat: 11 - Fingerprinting #13 (pipeline fingerprinting feature from spec 11; this PR implements standalone command spec 22 behavior)

Testing

• cargo test passes
• cargo clippy passes with no warnings
• cargo fmt has been run
• New tests added:
  • fingerprint::tests::returns_file_not_found_error_for_missing_file
  • fingerprint::tests::display_name_uses_basename_for_local_path
  • fingerprint::tests::display_name_uses_last_segment_for_cloud_path

Evaluation

• What was the specific scenario you tested?
  • Fingerprinting a temp local file.
  • Missing input file behavior.
  • Display-name rendering for local and cloud paths.
• What was the output before and after the change?
  • Before: sha256:... /full/path/to/file.parquet
  • After: sha256:... file.parquet
• Did you test error cases (bad input, missing files, invalid SQL)?
  • Yes: missing file is now explicitly mapped to File not found; cloud read errors are also mapped for missing credentials when identifiable.

Human review

• A human has reviewed the COMPLETE proposed diff before submission