Boundary-aware truncation for derived post summaries (word/sentence, not raw char count)

[mdorman]

Problem

#545 introduced PostSummary and, for the derived fallback summary label (used
when a post has no explicit summary), an infallible PostSummary::truncated(&str) door
plus the body-line extraction in PostRecord::fallback_summary_label /
render::derive_post_metadata. Both currently truncate on a hard character count:

• the body branch takes line.chars().take(100) (first non-empty body line),
• PostSummary::truncated takes s.chars().take(MAX_POST_SUMMARY_CHARS) (500).

Character-count truncation can cut mid-word (e.g. "…the quick brown fo") or
mid-sentence, producing an awkward auto-generated excerpt.

This does not affect a user-entered summary: PostSummary::FromStr (the submitted
path) rejects an over-cap value rather than truncating, so it never mangles user
input. Only the internally-derived label is at issue.

Proposed

Make the derived-summary-label truncation boundary-aware:

1. At minimum, cut on a word boundary — back off to the last whitespace within the
   cap rather than slicing mid-word (and consider a trailing ellipsis).
2. Ideally, prefer complete sentences — take whole sentences up to the cap, falling
   back to the word-boundary rule when even the first sentence exceeds it.

The character cap stays the hard ceiling (so PostSummary's ≤500 invariant is
preserved); this only changes where within the cap the cut lands. Scope is the two
derivation sites above; PostSummary::truncated remains the single infallible
length-validated door (it just gets smarter about the cut point).

Context

Follow-up to #545 (review feedback). Not urgent — the current hard-cut is correct and
bounded, just not polished.