Change “New note” navigation to hard reload (`location.assign('/')`) to improve reverse-proxy auth compatibility

[SJK-py]

What type of request is this?

Hosting or Self-hosting improvement

Clear and concise description of the feature you are proposing

Context / motivation

PUBLIC_VIEW_NOTE_PATH_PREFIX (added in #418) makes it much easier to expose a dedicated unauthenticated path for public note viewing when running Enclosed behind third-party auth (e.g., Authentik forward-auth). Also, the UI already has logic to conditionally display the “New Note” button based on authentication state (#379).

With Authentik-style setups, it’s common to:

• Require auth for the main app (/)
• Allow anonymous access to the public note view path (e.g., /${PUBLIC_VIEW_NOTE_PATH_PREFIX}/...)
• Allow anonymous GET access to read note APIs (/api/notes/...), while keeping POST authenticated

A user comment in #408 describes a UX issue in this setup: when an anonymous user is viewing a public note, clicking “New note” navigates to the create-note UI without triggering the reverse-proxy authentication challenge (because it’s client-side navigation). The actual note creation later fails (as expected) because POST /api/notes is still protected.

Problem

When accessing Enclosed through a reverse proxy that enforces auth on /, a user who is currently on the public view route can click “New note” and get routed to / without a full document request, so the reverse proxy never gets a chance to challenge the request at navigation time. This results in confusing UX: the create page loads, but “Create note” fails later due to missing authentication.

Proposed change (small)

In app.layout.tsx, change the newNoteClicked handler to perform a hard navigation:

From

const newNoteClicked = () => {
  triggerResetNoteForm();
  navigate('/');
};

To

const newNoteClicked = () => {
  triggerResetNoteForm();
  location.assign('/');
};

Expected behavior after change

When an anonymous user is on a public note view page and clicks “New note”:

• The browser performs a real request to /
• The reverse proxy (Authentik forward-auth) can then challenge/redirect to login immediately
• After login, the user lands on the create-note page normally

Notes / why this helps

• This is specifically aimed at deployments where Enclosed is used behind third-party authentication and only the public note view route is unauthenticated (enabled by feat(config): added a configuration to add prefix to the view note url #418’s configurable view-prefix).
• It doesn’t change server-side security boundaries (POST should still be protected); it only improves navigation UX and interoperability with reverse proxies.

Related

• [Feature Request] Support all notes on Specific Path for excluding from authentication #408 (public note view / reverse proxy auth setup discussion)
• feat(config): added a configuration to add prefix to the view note url #418 (view note URL prefix support)
• feat(ui): conditionally display "New Note" button based on authentication status #379 (conditionally display “New Note” button based on auth status)

Additional context

No response

Validations

• Check the feature is not already implemented in the project.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Check that the feature is technically feasible and aligns with the project's goals.