docs: record verified native preview and unfinished PWA parity

Replace current wrapper claims with native architecture/security/build evidence, preserve historical documents, track all thirty pages and explicit release gates, correct brand attribution and provide the twelve-section delivery report without claiming completion. Native signing remains paused and Apple application/device validation outstanding.

docs/server-compatibility.md

@@ -1,70 +1,41 @@
-# Server compatibility and authentication
+# Native server compatibility
 
-Source reference: upstream 2.78.0 revision
-`10bfef7686ed7303b4c74c7fcc55a5eb16356c9d`. No general version range has been
-certified. Anonymous bootstrap metadata deliberately omits the exact version;
-native probing verifies shape, not an invented minimum-version comparison.
+Reference: Yuvomi 2.78.0 at
+`10bfef7686ed7303b4c74c7fcc55a5eb16356c9d`. No general server-version range or
+complete native feature compatibility is certified.
 
-Use `https://family.example.com` or `https://family.example.com:8443`, backed by a
-root-hosted Yuvomi installation and a valid system-trusted certificate. Operators
-should set `SESSION_SECURE=true`, correct `BASE_URL`, and correct proxy trust.
-Private servers are supported through reachable HTTPS/VPN, not TLS bypasses.
-International hostnames should be entered in ASCII/punycode for both platforms.
+Enter a root HTTPS hostname, optionally with a custom port. HTTP, embedded
+credentials, query/fragment configuration and subpath deployments are rejected.
+Use a valid system-trusted TLS certificate and reachable VPN/LAN connectivity.
+No certificate bypass or proprietary mobile service is introduced.
 
-Root-relative assets, API endpoints, cookie paths, callback redirects and worker
-registration mean `/yuvomi/` subpaths are not supported by the inspected source.
-Use a dedicated hostname. Reverse proxies must pass `/api/v1/*`, cookies, HTML,
-JavaScript and the service worker consistently. An external authentication proxy
-that intercepts bootstrap calls is rejected with a connection error; it is not
-silently identified as a Yuvomi server.
+The native client probes the real public `/api/v1/version` and
+`/api/v1/auth/oidc/config` shapes. Anonymous metadata does not disclose the server
+version. An authentication proxy returning redirects/HTML instead of those JSON
+contracts is unsupported, not silently treated as a valid Yuvomi API.
 
 ## Authentication
 
-Password login, TOTP/recovery codes, password reset, invitations, server-side
-session expiry/revocation and logout remain upstream web flows. No native code
-stores the password, supplies a CSRF bypass, or extends an expired session.
-Backgrounding does not clear cookies. Native server erasure does not revoke a
-remote session; use Yuvomi logout first or revoke sessions server-side.
+The implemented native slice uses setup/password login, the existing two-factor
+verification endpoint, `/auth/me`, session cookies, CSRF headers and logout.
+Passwords are not stored. Native session persistence is separate from browser
+storage and protected by the platform keystore/keychain.
 
-### OIDC: local fixture verified; real-provider validation pending
+**Native SSO is not implemented yet.** The old wrapper's local-IdP WebView result
+does not apply to this client. The existing server protocol does not provide a
+generic browser-to-native session exchange for arbitrary self-hosted hosts; a
+reviewed solution is required. SSO-only deployments cannot currently use this
+native preview. Reset and invitation workflows also remain pending.
 
-The initiating Yuvomi session contains OIDC state, nonce and PKCE verifier. When
-the server redirects to an identity provider, native consent offers an isolated
-web sign-in window sharing the OS website cookie store. HTTPS-only redirects
-can return to the server callback; the final same-origin page returns to the main
-view. No app-capability handlers or JS bridge are installed in that auth window.
+Only initial dashboard/tasks/notes/shopping capabilities are implemented; see the
+[parity tracker](native-parity.md) for precise gaps. The complete server UI is not
+embedded to fill those gaps. Read-only and denied module permissions affect
+native controls; the server remains the enforcement point.
 
-Some providers (including configurations that prohibit embedded user agents)
-require a system browser. **Those cannot sign the native view in with upstream's
-current protocol.** Use Server settings -> Open server in browser, and sign in
-there for an independent browser session. Opening only the external authorization
-link in a browser does not transfer the initiating cookie. Browser cookies are
-never copied into the app, and custom-scheme callbacks are not fabricated.
+## Notifications, files and offline
 
-The API 35 integration suite completes a native isolated-window round trip with
-a local test IdP, real RS256 ID tokens, nonce and S256 PKCE. No external
-IdP/developer account was supplied. Validate the actual provider, including
-cross-site cookies, cancellation, errors, TOTP and account linking, before relying
-on that deployment. iOS authentication has not run against Apple SDKs. A native
-browser handoff would require an independently reviewed upstream protocol; no
-such upstream change is included or published.
-
-Android generated exports require a current WebView supporting document-start
-scripts and are capped at 25 MB. A bounded Blob registry preserves a generated
-file even when upstream immediately revokes its object URL; it does not fetch
-blob URLs or alter the server's CSP. HTTPS file downloads are capped at 100 MB.
-Update the system WebView if generated exports are unavailable on an old engine.
-
-## Notifications and offline
-
-Upstream implements Web Push and optional ntfy/Gotify/webhook/email channels.
-Embedded web views do not supply a portable native push subscription. This app
-has **no native remote-push claim**, no Firebase/APNs secrets, no background
-polling service, and no fake notification-registration UI. Configure an existing
-optional upstream ntfy/Gotify channel and its client if desired. No centralized
-service is required by this application.
-
-Upstream service-worker caching is read-only, allow-listed, and versioned.
-Mutations/authentication remain online. Platform-specific cache/resume behavior
-and offline account switching still need device validation. Do not rely on offline
-editing, synchronization, or closed-app push in this native development build.
+Native remote push, uploads/camera/download/export and offline caching/editing
+are not current native capabilities. The old wrapper's file handlers and the
+PWA service worker are not part of the native renderer. No fake registration or
+automatic offline mutation replay is supplied. Optional existing server-side
+ntfy/Gotify/email integrations remain independently operated upstream features.