docs(session): make the boundary's position and ownership conditional

Documentation only; no behavior change.

`firstLiveSeq`'s JSDoc still stated the boundary sits at that seq
unconditionally. Verified reachable on a plain production path: pick up a log,
do no work, pick it up again — the seed already ends in a boundary, so it is
not re-marked and `events[firstLiveSeq]` is undefined. Both that claim and the
firehose-gap sentence are now conditional, with the locate rule ("scan for the
last boundary") matching what types.ts already said.

`repair.ts`'s header claimed this module supplies the boundary. It does not —
the constructor does; this module supplies the activity read that must skip it.
Reworded, and it now names the closer timestamp leak, which is the one real
coupling that justifies `lastActivityTime` living beside the repair synthesis.

Recorded that `Session`'s constructor is the boundary's only legitimate writer,
since the invariant companion constrains nothing and a plugin-side append would
silently turn live brackets below it into dead history.

packages/core/session/src/index.ts

@@ -390,14 +390,17 @@ export class Session {
    * session's constructor seed is its full stored log, while its header keeps
    * the original fork value — this field is the in-process construction fact.
    *
-   * Not persisted itself: a nonzero value is projected into the log as the
-   * `session/inherited` event at this seq, which is what a consumer reading
-   * STORED history reads. Prefer this field in-process — it is exact before
-   * the marker's write reaches storage.
+   * Not persisted itself: a seeded session projects it into the log as the
+   * `session/inherited` event, which is what a consumer reading STORED history
+   * reads. Locate that event as the log's LAST boundary, not at this seq — a
+   * seed already ending in one is not re-marked, so reopening an untouched
+   * session leaves the boundary below `firstLiveSeq`. Prefer this field
+   * in-process: it is exact before the marker's write reaches storage.
    *
-   * The marker is appended before the store attaches, so when one exists the
-   * event AT this seq did not publish either: the firehose gap runs through
-   * `firstLiveSeq`, not just below it.
+   * When this lifecycle did append a boundary it sits at this seq, appended
+   * before the store attached, so that event did not publish either — the
+   * firehose gap then runs through `firstLiveSeq` rather than stopping below
+   * it. Otherwise this seq holds an ordinary published write.
    */
   readonly firstLiveSeq: number