refactor(dav): make chunk target resolution more explicit

[joshtrichards]

• Resolves: #

Summary

This refactor makes chunk upload target resolution more explicit by replacing the old file-only path with a richer resolver that returns:

• the target file
• the storage to use
• the internal storage path
• whether the upload is direct-to-target or staged

It also improves comments/docblocks around the upload lifecycle.

It is a focused internal refactor rather than a behavior change.

Core Changes

The main improvement is the new resolveChunkWriteTarget() flow:

• eliminates redundant calls (e.g. the former getUploadFile() followed immediately by getUploadStorage() which also then called getUploadFile()` again)
• the returned isDirect flag is then used later to decide whether finalization needs copy/move
• Direct writes are still allowed only when the destination file exists and is on the same storage as the upload folder (otherwise uploads go through the .target staging file), but the framework is there to easily expand the "direct-to-target" write scenarios supported.

The class’s actual unit of work is not just “file,” but “write target + storage + path + mode.”

Other Changes

• Resolver decomposition to improve readability and make the staging/direct distinction explicit.
• isDirect - from the centralized resolver - is used explicitly rather than finalization code inferring mode indirectly from path comparison.
• Clearer/consistent variable naming - i.e. $uploadFile only for UploadFiles

TODO

• Fix the spot in completeChunkedUpload() where I missed using the decompose
• Try to eliminate FIXME regarding File/etc return typing before merger
• Try to eliminate FIXME regarding public/private function declaration before merger

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI