docs(skills): guard both useAuth members in the auth-permissions example

The `useAuth` fence under "useAuth hook" read `user.name` behind an
`isAuthenticated`-only guard. `AuthProvider` hardcodes `isAuthenticated`
to `true` in guest mode and in preview mode while `user` stays `null`,
so the example threw a TypeError in exactly the two modes a reader
without an auth backend is in. Guard both members the way the shipped
`UserMenu` does, and add one sentence beside the fence saying why a
signed-in-looking context can still carry no user.

The fence stays unmarked: it is a fragment by construction (three
undeclared placeholders), and marking it would red the gate for reasons
that are not this defect.

Claude-Session: https://claude.ai/code/session_01DAcomhvR9kKizeYgg89Vo8
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/9350-auth-permissions-useauth-guard-both.md

@@ -0,0 +1,7 @@
+---
+---
+
+Guard both `isAuthenticated` and `user` in the `useAuth` example of
+`skills/objectui/guides/auth-permissions.md`, and say why beside it
+(objectui#9350). Published skills guidance only; no package is released by
+this change.

skills/objectui/guides/auth-permissions.md

@@ -35,14 +35,16 @@ function App() {
 
 ### useAuth hook
 
+Guard `user` on its own, not through `isAuthenticated`: in guest mode (`enabled: false`) and in preview mode, `AuthProvider` hardcodes `isAuthenticated` to `true` while `user` stays `null`, so a signed-in-looking context can still carry no user. The shipped `UserMenu` guards both members the same way.
+
 ```typescript
 import { useAuth } from '@object-ui/auth';
 
 function UserBadge() {
   const { user, isAuthenticated, isLoading, error, signOut } = useAuth();
 
   if (isLoading) return <Spinner />;
-  if (!isAuthenticated) return <LoginButton />;
+  if (!isAuthenticated || !user) return <LoginButton />;
 
   return (
     <div>