docs: document Teams, and correct what the Team work changed

[logicflakes]

The notification and ownership pages were written before Teams became a
first-class entity. They referenced teams as something the reader was assumed
to already know, pointed at a tab that no longer hosts assignment rules, and
described durability by a rule that has since changed.

New page: Teams

configure/teams.md -- what a team is (accountability, not access), what it
holds, why you would contain a user group instead of listing people, and what
archiving one actually does. That last part is the one worth writing down:
archiving a team silently stops delivery on every route targeting it and
degrades ownership of every component it owns, and nothing fails anywhere while
that happens.

Corrected, each checked against the code rather than carried over

• Assignment rules live under Organization Settings -> Teams now, not User
  Groups (they moved with fix(ui): restore userGroupPermissionsDirty, and move assignment rules to Teams #281).
• Durability is measured against the team's roster -- members plus everyone
  contributed by contained user groups -- or a contained SSO-backed group. The
  old text said "two direct members", which now understates a team of one that
  contains a ten-person group.
• The component Settings panel no longer reports a durability status, so the
  page no longer says it does; it points at the ownership report, which is where
  a fleet-level question belongs.
• The owner picker offers active teams only but still shows an already-stored
  archived owner, labelled. Documented because the alternative reading of an
  empty picker is "this component has no owner".

Added -- existing behaviour, undocumented, easy to get wrong

• A minimum severity on a subscription whose event types carry no severity does
  not narrow it, it silences it completely. Verified against
  extractEventSeverity and severityGateMatches.
• A dedup window of 0 means "deliver everything", and dedup cannot be
  demonstrated with the Test button, because synthetic events skip it by design.
  Testing twice always produces two deliveries, which reads exactly like dedup
  being broken.
• A test that reports no delivery has a third explanation beyond filter and gate
  whenever a route resolves through a team or an owner.

One claim I set out to document and found to be false

The UI hint and the perspectiveGateMatches javadoc both say perspectives make
release and approval events "match nothing", because only vulnerability events
carry affectedReleases. They do carry them: ReleaseChangeHookImpl (created /
lifecycle / bom-diff) and ApprovalEventNotifierImpl (requested / resolved)
both stamp buildAffectedReleases, and that helper copies the component's
perspectives onto each entry. A perspective-scoped route matches those event
types fine -- what it needs is a component that belongs to the perspective.

The page now says that. The stale UI hint is fixed in #282; the identical
javadoc claim lives in rearm-saas and is on the board
(t20260812-121545-31450).

Validation

npm run docs:build clean, with VitePress dead-link checking on (no
ignoreDeadLinks), so every new cross-reference and anchor resolves. Added
lines are plain ASCII.

[logicflakes]

Two-layer review: run, findings fixed

Layer 2 (ReARM-conventions subagent) and Layer 1 both ran. Fixes are in
89da155e and d2251792.

Layer 2 independently confirmed the perspectives reversal against the
producers -- ReleaseChangeHookImpl for all three release events,
ApprovalEventNotifierImpl for both approval events, and
ReleaseNotificationSupport.buildAffectedReleases stamping the component's
perspectives onto each entry. It also checked every other claim on the page
against the named source: org-admin gating, the field table, roster semantics,
lead validation, name uniqueness, archiving consequences, durability, the
severity gate, dedup-0 and the synthetic bypass. Those stand.

The real finding was merge order. Three sentences described UI that exists
only on #282, not on main:

• "the Settings panel does not report durability" -- on main it still shows the
  status chip and reason line;
• "an archived owner stays visible, labelled" -- on main the owner picker drops
  archived teams and renders a raw uuid;
• the (archived) label itself -- the route-target picker said (deactivated).

All three are now written so they are true on main today and remain true after
#282, rather than betting on merge order. Where a fact genuinely could not be
stated both ways, the page says the thing that matters instead: an archived
owner stays on record, reports DEGRADED, and stops receiving owner-routed
notifications.

Layer 2 also caught four text-level errors worth naming, because each was me
writing plausible prose instead of reading the code: the name-collision advice
told readers to infer an archived team when requireNameAvailable names it
outright; "set a team to inactive" named no control (it is Archive); the
rationale for name-and-description-only creation was invented, where
CreateTeamDto's javadoc gives the real one; and "every event type" overreached
past VEX_STATE_CHANGED, which has no producer.

Layer 1 found two more of the same kind: a CE note that described CE's ownership
model in a clause that could not be right (the mirror has
ComponentOwnershipService but no Team), and the last surviving
forward-looking label claim.

Out of scope, filed: the perspectiveGateMatches javadoc in rearm-saas
still carries the false claim this page corrects (t20260812-121545-31450). The
UI half is fixed in #282, along with normalising the route picker's team label to
(archived) so one state has one word across all three pickers.

Validation: npm run docs:build clean with VitePress dead-link checking on
(no ignoreDeadLinks), so every cross-reference and anchor resolves. Added lines
are plain ASCII.