feature: FileByteType

[maxbreuker]

Summary

This PR introduces validation modes for magic-bytes checks to support strict vs. lazy ("relaxed") validation rules for certain formats (currently: PDF). The main motivation is that many real-world PDFs are still considered valid by common viewers even if the %%EOF marker is not the very last bytes of the file, as long as it appears close to the end.

Motivation

Our current PDF validation requires %%EOF to be at the physical end of the file, which rejects PDFs that are tolerated by common PDF readers. A more compatible rule is: %%EOF must occur somewhere within the last 1024 bytes of the file. This PR adds a mode-aware validation path to support that without duplicating the PDF file type implementation.

What changed

• Added FileByteType validation modes:

  • Strict (intended for strict validation)
  • Lazy (intended for relaxed / viewer-compatible validation)

• Extended public APIs to accept an optional validation mode:

  • IFormFileTypeProvider.FindValidatedTypeAsync(..., FileByteType validationType = Strict)
  • IValidator.IsValidAsync(..., FileByteType validationType = Strict)

• Updated FileByteFilter so magic-byte checks can be registered either:

  • globally (applies to all modes), or
  • mode-specific (applies only to Strict or Lazy)
    by using the existing fluent methods with an optional FileByteType parameter.

PDF behavior

• Strict keeps the previous behavior: the file must end with one of the supported %%EOF variants.
• Lazy allows %%EOF to appear anywhere within the last 1024 bytes of the file (TailContains(1024, "%%EOF")).

Tests

• Updated Validator unit tests for the new validationType parameter.
• Added PDF unit tests to cover strict vs. relaxed (Lazy) behavior, including trailing bytes and the “last 1024 bytes” window.

Notes / Backwards compatibility

• Existing formats remain unchanged unless they opt into mode-specific checks.
• If callers do not pass validationType, the default is used (intended: Strict).

[maxbreuker]

The multiple list fields are intentional. I store checks by check kind (fixed offset / one-of / anywhere / tail-window) and by validation mode.
• The “base” lists are global and always evaluated. This keeps existing formats backwards compatible, because they continue to register checks without specifying a mode.
• The Strict lists are evaluated only when Matches(..., Strict) is requested.
• The Lazy lists are evaluated only when Matches(..., Lazy) is requested.

This avoids mutating filter instances at runtime and allows a single format (e.g. PDF) to define strict and relaxed rules side-by-side without duplicating file type classes.

I’m happy to adjust this if there’s a cleaner approach (e.g. grouping the lists into a small CheckSet per mode or using a dictionary-based structure) - suggestions welcome.