fix(shared-privacy): default all new records to 'space', not 'private'

Regression reported in testing: tasks and calendar events created via
the Workbench homepage widgets appeared there but vanished from their
respective module sub-routes (/todo, /calendar).

Root cause: my M4.b + M4.a shipped `defaultVisibilityFor('personal') →
'private'` based on the original plan ("personal space default is
private"). That collides with the pre-existing 2-tier visibility filter
in `apps/mana/apps/web/src/lib/data/scope/visibility.ts`, which treats
'private' records as "only the authorId sees them, even inside the
same space". Its applyVisibility() drops any 'private' record whose
authorId doesn't exactly match getCurrentUserId() — and the homepage-
widget cross-app queries in cross-app-queries.ts don't run that filter
while /todo/useAllTasks() does, creating the asymmetry the user saw.

Why the match can fail in practice: during auth bootstrap,
getEffectiveUserId() returns the 'guest' sentinel (which the Dexie
creating-hook stamps onto authorId), while getCurrentUserId() can
already resolve to the real user id by the time /todo's query runs.
authorId='guest' !== currentUserId=<real> → record filtered out.

Fix: defaultVisibilityFor() now returns 'space' regardless of space
type. Rationale:
- In a personal space there's exactly one member, so 'space' and
  'private' are effectively equivalent — both mean "only the owner
  sees it".
- In a multi-member space, 'space' is the desired default (otherwise
  every collaborative record would need a manual toggle).
- 'private' becomes an *active* user decision for drafts in shared
  spaces — click the VisibilityPicker to enable it.
- The parameter is retained (as `_spaceType`) for forward-compat so
  future space types can differentiate without touching call sites.

Impact on shipped modules: all 8 consumers (Library, Picture,
Calendar, Todo, Goals, Places, Recipes, Wardrobe) call
defaultVisibilityFor(activeSpace.type) at create time — they inherit
the fix automatically. No store edits required.

Existing records with visibility='private' from the testing window
stay as they are; user can flip them to 'Bereich' via the
VisibilityPicker, or reset the local Dexie to pick up the new default.

Plan doc updated with the full rationale (docs/plans/
visibility-system.md §Entscheidung).

Verified:
- pnpm test @mana/shared-privacy: 15/15 (defaults.test.ts updated)
- pnpm check (web): 7464 files, 0 errors

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/plans/visibility-system.md

@@ -47,10 +47,13 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public';
 | `unlisted`  | Wer den Direct-Link + Token hat; nicht gelistet, nicht indexiert | Event-Einladungen mit Nicht-Member-Gästen |
 | `public`    | Beliebig — sichtbar auf Website-Embeds, für AI-Agent referenzierbar | Ein aktiv als "für die Öffentlichkeit" markiertes Item |
 
-**Default bei Record-Create:** leitet sich vom Space-Typ ab.
-- Personal-Space → `private`
-- Team/Club-Space → `space` (sonst müssten User bei jedem Task manuell "meine Space-Mitglieder dürfen das sehen" setzen — unrealistisch)
-- Nie `public` oder `unlisted` als Default.
+**Default bei Record-Create:** **immer `space`**, unabhängig vom Space-Typ.
+
+Ursprünglich war Personal-Space → `private` geplant. Nach der ersten Integration (M4.b Todo) stellte sich heraus: das existierende 2-Stufen-System in `scope/visibility.ts` behandelt `'private'` als "nur der Author sieht es, auch innerhalb des gleichen Space" — und filtert solche Records im `applyVisibility()`-Aufruf der Modul-Queries. Das fightet mit dem "Personal-Space default = private"-Plan: neu angelegte Tasks/Events erschienen im Homepage-Widget (das keinen Filter nutzt), verschwanden aber auf `/todo` (Filter schlägt zu). Der `authorId`-Check in `applyVisibility` versagt während des Auth-Bootstraps, wenn der Hook `'guest'` als authorId stempelt aber `getCurrentUserId()` bereits den echten User zurückgibt.
+
+Der robuste Fix: `defaultVisibilityFor()` returnt immer `'space'`. Im Personal-Space (1 Member) ist das semantisch äquivalent zu `'private'`. In Multi-Member-Spaces ist `'space'` der erwünschte Default (sonst müssten User jeden Task manuell für ihre Mitglieder freischalten). `'private'` wird zur **aktiven User-Entscheidung** für Drafts in geteilten Spaces — Klick im VisibilityPicker.
+
+- Nie `public` oder `unlisted` als Default (deny-by-default-Regel bleibt).
 
 **Begründung der Namen:** `visibility` + 4-Stufen-Enum ist das vertraute Google-Drive/YouTube-Mental-Model. Alternativ diskutiert: `sharingLevel`, `audience`. Verworfen — `visibility` ist breiter bekannt und technischer neutral (keine "Zuhörerschaft"-Assoziation).
 
@@ -68,8 +71,11 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public';
 export const VisibilityLevelSchema = z.enum(['private', 'space', 'unlisted', 'public']);
 
 // defaults.ts
-export function defaultVisibilityFor(spaceType: SpaceType): VisibilityLevel {
-  return spaceType === 'personal' ? 'private' : 'space';
+export function defaultVisibilityFor(_spaceType: SpaceType | null | undefined): VisibilityLevel {
+  // Always 'space' — compatible with the existing 2-tier applyVisibility
+  // filter, and semantically equivalent to 'private' in personal spaces
+  // (only one member). Users flip to 'private' explicitly for drafts.
+  return 'space';
 }
 
 // predicates.ts