"Mine" filter shows external storage files as owned by everyone

[moodyjmz]

External storage mounts (S3, SMB, local, etc.) report the current session user as owner-id regardless of real ownership, and the "Mine" filter in OfficeOverview.vue only excludes group/shared mount-types — so external slips through and those files show as "Mine" for every user who has the mount. Confirmed the actual affected mount is S3-backed external storage.

Reproduced locally (with a local backend mount, since ExternalMountPoint::getMountType() returns the same external value regardless of storage backend — S3, SMB, or local all hit the same code path): the same file on a shared external storage mount returns owner-id: admin when queried as admin and owner-id: alice when queried as alice.

[moodyjmz]

Reopening: the fix for this issue likely never took effect.

src/utils/fileFilters.ts:20-28's NON_MINE_MOUNT_TYPES exclusion (added to close this issue) checks f.attributes?.['nc:mount-type']. Verified two ways — empirically parsing a synthetic multistatus response through the exact fast-xml-parser config the webdav client uses (removeNSPrefix: true, set in node_modules/webdav/dist/node/tools/dav.js), and independently by testing under Node 24 — that DAV response keys always have their namespace prefix stripped. The real attribute is mount-type, never nc:mount-type.

That means NON_MINE_MOUNT_TYPES.includes(f.attributes?.['nc:mount-type']) evaluates .includes(undefined) and is always false: the exclusion never fires. External-storage/group/shared mount-types are never excluded from "Mine," so the original bug — files with no real per-mount owner showing as "Mine" for every user with that mount attached — is likely still present in production.

It stayed invisible because src/test-utils/fixtures.ts hardcodes the same wrong key (nc:mount-type), so the tests that validated the original fix pass against a fixture that doesn't match what the real DAV client actually returns. Same root cause also breaks the "Shared with me" filter (fileFilters.ts:30), which reads the identical wrong key.

Fix should be a one-line key rename (nc:mount-type → mount-type) in both fileFilters.ts branches, plus correcting the fixture so the tests would have actually caught this, plus ideally a test that exercises real DAV XML parsing end-to-end rather than a hand-authored fixture object, so a future key-naming mismatch like this one doesn't slip through the same way again.

Found during review of #125/#127, unrelated to either PR — flagging here rather than there since it's pre-existing and independent of both.