fix(getPod): support path-based pod servers

[melvincarvalho]

Summary

The getPod() function previously assumed subdomain-based pods by using document.location.origin. This broke path-based pod servers like JSS and CSS in path mode.

Changes

Now getPod() first checks if a user is logged in and looks up their pim:storage from their profile. Falls back to origin-based detection for backwards compatibility with subdomain-based servers.

The Problem

For a path-based pod server:

• WebID: http://server.com/alice/profile/card#me
• Pod root: http://server.com/alice/
• Old getPod() returned: http://server.com/ ❌
• New getPod() returns: http://server.com/alice/ ✓ (from pim:storage)

Testing

Tested with JSS (JavaScript Solid Server) which uses path-based pods.

Fixes: #651

[Copilot]

Pull request overview

This PR fixes the getPod() function to support path-based pod servers (like JSS and CSS in path mode) by checking the logged-in user's pim:storage from their profile before falling back to origin-based detection.

Key Changes:

• Updated getPod() to first attempt retrieving pod location from user's pim:storage property
• Added fallback to original origin-based detection for backwards compatibility with subdomain-based servers
• Imported authn and store from solid-logic to access user profile data

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new logic for retrieving the pod from the logged-in user's pim:storage lacks test coverage. This is a critical change that introduces different behavior for path-based pod servers versus subdomain-based pod servers. Consider adding unit tests to verify:

1. When a user is logged in and has pim:storage in their profile, the function returns the storage value
2. When a user is logged in but has no pim:storage, the function falls back to origin-based detection
3. When no user is logged in, the function falls back to origin-based detection
4. When multiple storages exist, the function returns the first one

This is especially important since the function is already exported for testing (as noted in the comment on line 16).

[bourgeoa]

@melvincarvalho
By solid specification

1. Storage Discovery via Headers
   When an app interacts with a Solid resource (like a file or folder), the server includes specific headers to tell the app about the storage environment.

rel="type": If you perform a HEAD or GET request on a folder and see Link: http://www.w3.org/ns/pim/space#Storage; rel="type", the server is explicitly stating that this URI is the Root Storage (the top level of your Pod).

rel="http://www.w3.org/ns/solid/terms#owner": This header is often found at the storage root to identify the WebID of the person who owns that storage space.

[melvincarvalho]

Thanks for the pointer Alain! You're right that header-based discovery is also in the spec. This PR uses pim:storage from the profile since it follows the linked data pattern of dereferencing the WebID and reading the triples. The main goal here is fixing path-based pod support — the previous code assumed subdomain-based pods which broke servers like CSS running in path mode.