fix(bgtail): a wider lines window returns the earlier lines, not "no new lines"

[lloydsk]

What

bgtail's delta bookmark recorded the log path and the search window, but not how many lines the caller had already been shown. A repeat read asking for a wider window therefore fell into the appended-lines path — fresh was empty — and the tool answered:

(no new lines since last read — log at 238 lines)

That replies to the wrong question. The caller had just asked to see more of the tail, and the answer reads as "nothing more to see", while the lines it asked for had never been shown.

Seen in practice against the repo's own suite: bgtail(lines: 60) → 5,238 chars, then bgtail(lines: 80) → 49 chars of (no new lines since last read — log at 238 lines).

Change

• The bookmark gains served — the trailing content lines the caller has been shown. A later read is a widening when lines > served and the log holds lines older than served.
• It returns only rawLines.slice(total - lines, total - served): the earlier lines, and never the whole window again. details.widened marks the response.
• Bounded by what exists: once served === total there is nothing older to hand over, so the cheap poll response stands.
• Narrowing is unchanged, and appended lines still win over a widening; served advances with contiguous coverage.
• The raw / reset / shrink / replaced / changed-window paths reset served, since each re-establishes a full tail.

Verification

• tsc --noEmit clean.
• 226 tests pass, including the widening boundaries (first read, widening, narrowing, full coverage, appended-lines precedence) and the shrink path below.
• A live pi session through the real tool interface: lines: 3 then lines: 6 on a 12-line log returned exactly the three earlier lines with the widening header.

Follow-up from review (third commit)

Verdict: incorrect, non-blocking. The widening works and no path can hide an appended line, but the claim "never the ones already in your context" is false when coverage has a gap — served tracks only the contiguous trailing run, so a delta read showing fewer lines than were appended (fresh.length > lines) sets served = lines and forgets a larger earlier coverage; a reset read with a narrower lines shrinks it too.

Reproduction (13-line log): lines: 5 → shows 6–10; append 11–13; lines: 2 → shows 12–13 (line-11 never shown); lines: 4 → returns line-10 again, plus line-11.

Landed:

• the claim is accurate in all five places that made it — the trigger is "more lines than you have already been shown" (matching the lines > served guard rather than the misleading "than last time"), and the return is "the lines above your current coverage", with the possible repeat stated;
• a test pins the half that matters: after the shrinking read, a widening still returns the line nothing has shown — and it deliberately does not assert the repeat, so a dedup fix can land without breaking it;
• the true-dedup work (a scalar served cannot express a gapped coverage) is filed as bgtail: a widening can repeat a line the caller already saw when coverage has a gap #28, with the reproduction and three options.

[github-actions]

CI report

Check	Result
tsc --noEmit	success
tests	success
npm pack --dry-run	success (7 files in tarball)

Ref: 768102520ae4be2a73573d8b1ecfcc77069eb134