fix(admin): auto-approve member logo uploads that pass format/size/safety checks

[bokelley]

Closes #2568

Member logos uploaded during onboarding sit in a pending review queue indefinitely — no admin UI exists to process it, the only consumer is an Addie MCP tool (list_pending_brand_logos) most admins don't know to invoke, and members see a hardcoded "pending review" message with no resolution path. This is the escalation source identified in the Apr 11–18 Addie insights.

This PR removes the bottleneck by auto-approving all uploads that already pass the membership + ban + magic-bytes + SVG-sanitization + size gates. Source traceability (brand_owner vs community) is preserved. The reject/delete admin path is unchanged. The upload_brand_logo Addie tool was a separate code path with the same hardcoded pending logic — it's fixed in the same diff.

Non-breaking justification: No schema or wire changes. review_status was already returned in the HTTP upload response; callers that read it now see 'approved' instead of 'pending'. No existing client depends on community uploads being held in pending state.

Files changed:

• server/src/routes/brand-logos.ts — reviewStatus always 'approved'; manifest rebuild unconditional; edit summary records source
• server/public/brand-viewer.html — success message uses result.review_status from API response
• server/src/addie/mcp/brand-tools.ts — upload_brand_logo tool: insert approved, call rebuildManifestLogos, return correct status; description updated
• server/src/db/brand-logo-db.ts — insertBrandLogo default changed from 'pending' to 'approved' (latent footgun fix)
• server/src/addie/jobs/brand-logo-digest.ts — comment updated: job is now a drain for pre-deploy pending logos only
• .changeset/auto-approve-verified-owner-logos.md — removed contradicting note that community uploads still queue

Nits surfaced in review (not fixed here):

• countBrandLogos and getByDomainAndSha256 still reference IN ('pending', 'approved') — functionally fine, cosmetic cleanup follow-up
• rebuildManifestLogos + editDiscoveredBrand are two sequential writes to the same brand row per request with no transaction wrap — pre-existing race under concurrent same-domain uploads; tracked separately

Pre-PR review:

• code-reviewer: approved — no blockers; XSS surface in HTML change is safe (message chosen from two hardcoded literals, not user input); rebuildManifestLogos placement correct in both code paths
• internal-tools-strategist: approved — DB default fix and digest annotation address the two operational blockers; isOwner is still needed for source field and audit summary so the call is not dead

Triage-managed PR. This bot does not currently iterate on
review comments or PR conversation threads (only on the source
issue). To unblock:

• Push fixup commits directly: gh pr checkout <num> →
  fix → push.
• Or re-trigger: comment /triage execute on the source
  issue.

See #3121
for context.

Session: https://claude.ai/code/session_019WyF5yW7B8jkypARtKHqcg

---

Generated by Claude Code

[bokelley]

TypeScript Build is failing — need to investigate which test imports member-context or auth chain that's now broken. Common pattern: lazy-import the problematic dependency, or add proper vi.mock() for auth/workos in the failing test. Reference: PR #3258's lazy-import fix.

[bokelley]

Fixed in 634ff75.

admin-tools.ts line 21 had a top-level import { invalidateMemberContextCache } from '../member-context.js' that wasn't covered by PR #3258 (which fixed the same pattern in member-tools.ts). That import pulls in member-context.ts → middleware/auth.ts → new WorkOS(WORKOS_API_KEY!) at module load time — any test importing admin-tools.ts without WORKOS_API_KEY set fails.

Applied the same lazy-import fix: removed the top-level import and replaced both call sites (lines 7672 and 7784) with const { invalidateMemberContextCache } = await import('../member-context.js') inside the handler bodies.

---

Generated by Claude Code

[bokelley]

Acknowledged — lazy-import fix in 634ff75 looks correct, same pattern as the #3258 fix in member-tools.ts. No further action needed on this thread.

---

Generated by Claude Code

[bokelley]

Routine: this PR is DIRTY against main. Please rebase against origin/main, resolve conflicts (likely in admin-side logo/brand files since other admin PRs landed), and re-push. No content changes needed — just the rebase. Mary launch blocker, please prioritize.

[bokelley]

Routine: persistently DIRTY against main as other PRs land. Please rebase locally against origin/main, resolve conflicts, and force-push. Once green and rebased, will admin-merge.

[bokelley]

Rebased against origin/main and force-pushed.

One modify/delete conflict on .changeset/auto-approve-verified-owner-logos.md (deleted in main, present in the PR commit) — resolved by accepting the deletion; the replacement changeset logo-auto-approve-onboarding.md was already in the commit and carried through cleanly. Branch is now two commits ahead of main with no conflicts.

---

Generated by Claude Code

[bokelley]

Got it — rebase noted, conflict resolved cleanly, logo-auto-approve-onboarding.md carried through. Branch looks good from here.

---

Generated by Claude Code

[bokelley]

Acknowledged — glad the rebase carried through cleanly. No action needed on my end.

---

Generated by Claude Code

[bokelley]

Noted, thanks for confirming. No further action from this end.

---

Generated by Claude Code

---

Generated by Claude Code

[bokelley]

Acknowledged — standing by if anything else comes up.

---

Generated by Claude Code

---

Generated by Claude Code