fix(webdav): bump storage usage on PUT, not just REST multipart upload

update_file_streaming_with_perms (the method behind every WebDAV/
NextCloud/WOPI PUT) never called the storage-usage-delta hook, so
drives.used_bytes and the RFC 4331 quota-used-bytes property never
reflected content written via WebDAV — only the REST multipart
upload path bumped usage. Extract apply_storage_usage_delta() from
maybe_update_storage_usage() and wire it into both branches: the
overwrite path applies new_size - old_size, the create path applies
the full size.

Also fixes the two RFC 4331 hurl tests that caught this:
nc_webdav_quota_properties.hurl had a Hurl parse error ([BasicAuth]
section keys can't mix literal+template, so the {user}~{folder}
composite marker is now pre-resolved via [Options] variable: before
being referenced as a single template), and both quota-properties
tests now retry the post-upload PROPFIND (matching the existing
drive_quota.hurl/user_envelope_quota.hurl pattern) since the delta
is applied fire-and-forget on a background task.

tests/api/webdav_quota_properties.hurl

@@ -203,10 +203,18 @@ Content-Type: text/plain
 HTTP 201
 
 
+# The drive-usage bump is fire-and-forget on a tokio task (see
+# `file_upload_service.rs::maybe_update_storage_usage`), so the SQL
+# UPDATE may not have landed yet when the PUT above returned. Retry
+# the PROPFIND until `used_bytes` catches up — same shape as
+# `drive_quota.hurl` Step 5.
 PROPFIND {{base_url}}/webdav/@drive/{{wq_drive_id}}/
 Authorization: Bearer {{wq_owner_token}}
 Depth: 0
 Content-Type: application/xml; charset=utf-8
+[Options]
+retry: 10
+retry-interval: 200ms
 ```
 <?xml version="1.0" encoding="utf-8"?>
 <D:propfind xmlns:D="DAV:">