[Feature Request]: Support /m/auth mobile deep-link route for self-hosted instances

Description

On a self-hosted Plane instance, mobile app authentication / email deep links attempt to open the /m/auth URL path, which returns HTTP 404 Not Found.

Current Behavior

Clicking a mobile deep link (from the app or an authentication email) that targets /m/auth results in a 404 response from the self-hosted instance. Reviewing the web frontend routing source and the transactional email templates in this repository shows no route registered for that path — it appears to be an endpoint the official (closed-source) mobile app clients expect, but which self-hosted deployments never implement.

Expected Behavior

Self-hosted instances should either:

• Implement a /m/auth route that completes the mobile deep-link handoff (matching whatever the official app clients expect), or
• Document the intended self-hosted mobile-auth flow so operators can implement an equivalent redirect themselves.

Workaround (if any)

None found in the open-source codebase. A reverse-proxy redirect from /m/auth to the standard web sign-in page avoids the 404 but does not complete a native app deep-link handoff (any auth token parameters in the original URL are lost).

Environment

• Deployment: self-hosted (Docker/Kubernetes), current release
• Relevant config: standard self-hosted install, no custom auth provider

Start by tracing the /m/auth entry point through the web frontend routing source and reviewing the transactional email templates that generate mobile links. Compare the available self-hosted flow with the official mobile client expectations; the work is done when the route completes the intended handoff or the documented operator redirect flow preserves the required authentication parameters.