sharing-pane: anonymous users see raw '401 Unauthorized' instead of 'Log in to manage sharing' #8

Problem

When an unauthenticated visitor opens the Sharing tab on any pod resource, the pane renders a red 401 Unauthorized banner. This is the legitimate response from the server (reading ACL needs a WebID), but as UX it reads like an error rather than a missing-auth state.

Repro

1. Open melvin.solid.social/public/ in a private window (no session)
2. Click Sharing tab
3. See: red 401 Unauthorized banner

Proposed shape

When canHandle runs and there's no auth context (window.xlogin?.account / localStorage token / however the pane currently checks), short-circuit the ACL fetch and render:

Log in to manage sharing
[Login button or link to existing xlogin flow]

Optionally still show the public-access toggle in a read-only state (with a tooltip "Log in to change") so the page isn't empty.

If canHandle can't tell whether auth is available without firing the request, then catch the 401 in render and swap the empty-state UI in.

Out of scope

• Changing the server's 401 response — that's correct behavior.
• The hard-reload race for authenticated users — that was the bug fixed in Hard-reload race — sharing-pane 401s before xlogin restore settles #6.

Acceptance

• Anonymous user on Sharing tab sees a friendly "Log in to manage sharing" empty-state, not a red 401
• Authenticated user with a WebID sees the existing ACL controls (no regression)
• Authenticated user who genuinely lacks read access on the resource still sees a real 401 (this is a different case — log-in won't help them)