Account for pending XFTP files in storage quota

[spencer-michaels-1pw]

Summary

PR #1814 changed startup storage accounting to count only files that had completed upload. As a result, pending file records created by FNEW currently don't consume the configured storage quota, even though those records remain in the file store and are even restored after a restart.

This fix reserves the advertised size for each file record before it is created and keeps the reservation in place while the file is either pending, uploaded, or blocked; reservations are only released upon deletion. After a restart, reservations are reconstructed from the stored records. In addition, the deletion APIs now return the amount of reserved space to release, ensuring that repeated or overlapping deletion attempts cannot release it more than once.

A record's quota is released only after the record is successfully removed from the store. Deletion returns the deleted file’s size only when it actually removes the record, so repeated or concurrent deletion attempts cannot release the same quota twice. The quota arithmetic also rejects overflow and underflow to ensure that the counter remains valid.

Tests added

• Quota enforcement when FNEW creates pending records
• Concurrent file creation when the quota is almost maxed out
• Restoration of pending reservations after a restart
• Retention of reservations for blocked records
• Quota is released only once even if multiple cleanup attempts target the same file
• Underflow handling during quota release