Describe the bug

When attempting to download multiple files (which triggers the Archiver/ZIP download) via a Public Link shared from a Project Space, the request fails with 401 Unauthorized. Single-file downloads from the same link work correctly. Public links shared from Personal folders (User-owned) allow multi-file downloads without issue.

Steps to reproduce

1. Create a "Project Space" (Type 8).
2. Create a Public Link for a folder within this Space (allow download).
3. Open the Public Link in an incognito browser window.
4. Select multiple files.
5. Click "Download" (to trigger the ZIP generation).
6. Result: The browser receives a 401 Unauthorized response. The ZIP download fails.

Expected behavior

The Archiver service should correctly validate the signed URL for Space-owned resources and serve the ZIP file, just as it does for Personal resources.

Actual behavior

The request to /archiver returns 401. Server logs indicate a "User not found" error during the signed_url authentication phase.

Setup

Started via Docker Compose with OIDC (Keycloak).

services:
  ocis:
    image: owncloud/ocis:7.3.1
    environment:
      OCIS_URL: https://ocis.example.com
      PROXY_AUTOPROVISION_ACCOUNTS: "true"
      PROXY_USER_OIDC_CLAIM: "preferred_username"
      PROXY_USER_CS3_CLAIM: "username"
      OCIS_JWT_SECRET: "..."

Additional context

Environment:

OCIS Version: 7.3.1 (Compiled: 2025-11-25)
OS: Linux
Log Analysis & Hypothesis: We compared logs between a successful Personal download and a failed Space download.

Failed Request (Space Public Link): The signed_url authenticator attempts to resolve the user associated with the claim (likely sub). It extracts the Space ID (Resource Owner) and attempts to look it up in the User Provider. Since the ID belongs to a Space (Type 8), not a User (Type 1), the lookup fails (Could not get user by claim).

{"level":"debug","service":"proxy","authenticator":"signed_url","message":"rewrite hook found"}
{"level":"error","service":"proxy","error":"user not found","message":"Could not get user by claim"}
{"level":"info","service":"proxy","status":401,"path":"/archiver"}
Successful Request (Personal Public Link): For personal folders, the Resource Owner is a User. The lookup succeeds, and authentication passes.

The issue appears to be that the Archiver service incorrectly assumes the resource owner in the signed token is always a User, causing failure for Space-owned resources.