docs(file-storage): document custom upload content-type detection

[kamilmysliwiec]

PR Checklist

• The commit message follows our guidelines: https://github.com/nestjs/docs.nestjs.com/blob/master/CONTRIBUTING.md

PR Type

• Docs

What is the current behavior?

Closes #3599.

The file storage chapter doesn't mention the detectContentType and contentTypeSampleBytes options that uploadToDisk() gained in nestjs/storage#13 (released in @nestjs/storage 0.0.2). A reader who wants CSV uploads would add text/csv to contentTypes and find every upload refused with a 415.

What is the new behavior?

• A new Accept CSV and other text formats subsection at the end of Upload product photos. Staff upload a price list, recognized by its header row, to the private disk. It covers:
  • built-in signature detection runs first;
  • the 4 KiB prefix and contentTypeSampleBytes;
  • parameter-insensitive matching against contentTypes, with a 415 before any write;
  • what happens without an allow-list;
  • the returned type and .csv extension being used for storage and the key;
  • async detectors;
  • a warning that classifying a prefix doesn't validate the file.
• The first "three things" bullet now says which formats are built in and links to the new subsection.
• Reference: both options added to the uploadToDisk() row. The detectContentType(bytes) row now separates the exported helper from the option.

Every behavior described was checked against @nestjs/storage 0.0.2: directly against uploadToDisk(), and through a real Nest + multer app for the HTTP statuses (CSV 201, unknown header 415, throwing or non-string detector 500, thrown HttpException keeps its status).

Does this PR introduce a breaking change?

• No

Other information

npm run build passes, and the dangling-links list has no new entries. The example decodes with TextDecoder rather than replace(/^/, ''), because the markdown pipeline turns that  escape into a literal, invisible BOM.