posixfs: nodes without parentid xattr (stale .mlock files, unfinalized-upload dirs) fail whole parent listing with 500

## Describe the bug

On oCIS 8.2.0 (Docker, `STORAGE_USERS_DRIVER=posix`, ~190 GB, local ext4/md-raid, `inotifywait` watcher), PROPFIND on some folders started failing with HTTP 500 `list container: internal error: Missing parent ID on node`. The desktop client blacklisted hundreds of files as a consequence. Restarting only helped until the in-memory assimilation cache was repopulated.

Root cause found on disk: **nodes without the `user.ocis.parentid` xattr**:

1. One real directory (`REV 2`) had no ocis xattrs at all — likely created during heavy parallel-upload churn. Listing its parent always 500'd.
2. **326 stale, 0-byte `.mlock` files without any xattrs** spread across all project spaces (some dating back to Dec 2025). Any folder containing one of them 500'd on listing.

Healthy sibling for comparison:

```
# file: .../Edificio IDIEM/Planos HC
user.ocis.dirty="false"
user.ocis.id="307fac1e-8302-445a-aaf4-b67965e3e8bc"
user.ocis.name="Planos HC"
user.ocis.parentid="5885b9a0-3fd8-4909-b756-35357e92ceb2"
user.ocis.propagation="1"
...
```

vs the broken dir (no output at all from `getfattr -d -m user.ocis`), and 0-byte `.mlock` files with zero xattrs.

Server log (trace tail):

```
service=ocdav path="/_Comerciales/Edificio IDIEM"
status={"code":15,"message":"list container:internal error: Missing parent ID on node"}
→ proxy PROPFIND status 500 (durations 38–65 s, retried by client every ~10 s)
```

## Triggers observed

- Heavy parallel uploads from desktop clients (multiple TUS sessions for the same file, `Offset==Size` but `IsFinal:false`, never finalized; 5 concurrent sessions seen for one 2.5 MB file edited repeatedly in AutoCAD).
- Deleting 0-byte "processing" nodes directly on the filesystem while TUS sessions still reference them (admin cleanup) — matches the delete-during-postprocessing race in #7909.
- Stale lock remnants: all 326 bad `.mlock` files were 0 bytes with no xattrs; healthy (recent) `.mlock` files do carry xattrs, so these look like remnants of an older code path that created lock files without metadata.

## Workaround applied

- Repaired the directory xattrs manually (`user.ocis.id` fresh UUID, `parentid`, `name`, `type=2`, `treesi ze=0`, `dirty=false`, `propagation=1`, empty `tmp.etag`, current `tmtime`).
- Deleted all 326 xattr-less 0-byte `.mlock` files (verified none had content first).
- Restarted oCIS to flush the assimilation cache. PROPFINDs went from 100% 500 to 100% 207.

Note: `ocis storage-users uploads delete-stale-nodes` does not help on posix — it looks under the decomposedfs layout (`/var/lib/ocis/storage/users/spaces/...`) and reports `Total stale nodes: 0`. And `uploads sessions` panics in this setup with `need nats for async file processing`.

## Expected behavior

- A single node without metadata should not fail the listing of its whole parent container (skip + warn, or self-heal by re-assimilating the node on the fly).
- Lock files should never be left behind without xattrs; stale 0-byte `.mlock` files should be ignored by the tree walker and/or cleaned up automatically.
- `delete-stale-nodes` should support the posix driver.

## Setup

- `owncloud/ocis:8.2.0` (compiled 2026-08-30), single Docker container, Ubuntu 22.04 host
- `STORAGE_USERS_DRIVER=posix`, `STORAGE_USERS_POSIX_ROOT=/var/lib/ocis-storage/`, `WATCH_TYPE=inotifywait`, `SCAN_DEBOUNCE_DELAY=4s`, `USE_SPACE_GROUPS=true`, `ID_CACHE_STORE=nats-js-kv`
- Desktop clients mirall 5.3.2 (Linux) and 6.0.3 (Windows)

## Related

- #10522 (async propagation vs delete race leaving parentid-less nodes)
- #7909 (delete during post-processing corrupts state)
- #11093 (mlock avalanche on PosixFS — likely same lock machinery)
- opencloud-eu/opencloud#2604, #2821 (same `Missing parent ID on node` on posix)

Start at the POSIX storage driver's PROPFIND/listing path and the `Missing parent ID on node` error; compare the behavior with related issues #10522, #7909, and #11093. Reproduce the case with parentid-less nodes or stale 0-byte `.mlock` files, then verify that one malformed node no longer causes a whole parent listing to return 500 and that stale lock remnants are handled.

Written by the indexing model from the issue text.