feat: the empty front door is the install's first screen (milestone 387 step B4)

The front door is now a feed, and a blank feed implies things should be
here in a way a blank masonry does not. On a fresh install this is the
first screen anyone sees — including someone who is not the operator,
which is what milestone 328 is making possible.

Tells the two empties apart, which is the point. "No sources yet" gets
the on-ramp; "sources configured, nothing landed yet" gets told that
the first check takes a while and pointed at Downloads. Telling someone
to add a source when they already have three and are mid-backfill reads
as the app not knowing its own state.

Needs total_sources on schedule-status to distinguish them —
deliberately not auto_sources, which counts only what is on a schedule,
so a source with auto_check off would have read as "nothing
configured". Both exact-shape assertions updated in THIS change rather
than after CI caught them, which is the lesson from B3's red push.

An absent status falls back to the on-ramp on purpose: it is merely
redundant to an established operator, whereas "see what's running"
shown to someone with nothing configured is a dead end.

A filtered miss is deliberately NOT the onboarding case — the operator
has posts, they just narrowed past them. Showing a fresh-install
on-ramp there would tell someone with a full library to go set it up.

This is where logo.svg lands, as the operator asked. It earns its place
on a first-run screen and not on a populated feed, and gives the
on-ramp something to compose around instead of prose plus two buttons.
Large: the mark stops reading below ~48px, which is why the 22px nav
slot has a different one. Pinned by test so a later tidy-up cannot
quietly shrink it to a glyph.

Also extracts mountWithStore into the shared test support module.
Writing the second spec created exactly the copy-paste that open issue
3109 tracks for the backend row factories, so it is consolidated now
rather than at copy three, and recorded as snippet 3829 with the two
traps it does NOT solve — named slots rendering nothing, and
components that fetch on mount.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LNXXULQDjVZmbuNa2G9mD9

frontend/test/components/feedStatusRibbon.spec.js

@@ -3,7 +3,7 @@ import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest'
 
 import FeedStatusRibbon from '../../src/components/posts/FeedStatusRibbon.vue'
 import { useSourcesStore } from '../../src/stores/sources.js'
-import { freshPinia, mountComponent } from '../support/mountComponent.js'
+import { mountWithStore } from '../support/mountComponent.js'
 
 // #387 B3. This ribbon is the ONLY place phase A's work reaches someone who
 // wasn't already looking for it, so what it does and does not say is the whole
@@ -12,11 +12,9 @@ import { freshPinia, mountComponent } from '../support/mountComponent.js'
 // zero — a "0 failing" on the front door is noise that trains you to ignore
 // the line, which is exactly what would hide the real number later.
 
-function mountWith (status) {
-  const pinia = freshPinia()
+const mountWith = (status) => mountWithStore(FeedStatusRibbon, () => {
   useSourcesStore().scheduleStatus = status
-  return mountComponent(FeedStatusRibbon, { pinia })
-}
+})
 
 describe('FeedStatusRibbon', () => {
   beforeEach(() => {