Default body_inline_max_bytes to 16384 so small records are stored inline, not as Files

The shipped default for body_inline_max_bytes is 0, which disables inline storage entirely: every body, including small structured records, is sealed and written to a managed File in private://.

For pdv's data shapes that is the wrong default. Records are small and numerous, and the File path is the heaviest and most failure-prone option for them: each record becomes a File entity plus a physical file plus a file_usage row, carries orphan risk on an interrupted delete, and consumes an inode. Inline storage is row-atomic (created, deleted and crypto-erased with the row; no orphaned files, no file_usage bookkeeping), which is the better fit for small bodies.

Real documents (scans, PDFs) are tens of KB to several MB, well above 16 KB, so they still take the File path. 16384 sits comfortably in the gap between the largest realistic record and the smallest realistic file, and keeps the eager-load footprint modest (the body column is loaded with the entity on listings). 0 remains available for operators who prefer a DB-footprint-first, all-File deployment.

Change

• Set the install default body_inline_max_bytes to 16384 in config/install/pdv.settings.yml.
• Update the Vault::shouldStoreInline() docblock, which still described 0 as the default.

Scope

This changes the shipped default for fresh installs only; existing sites keep their configured value. The threshold is re-evaluated per item on update, so the change is non-disruptive (no migration, no update hook): existing rows keep their current storage until re-saved. No test depends on the old default (the storage tests set the threshold explicitly).