Evidence for boot-service.log rotation

Environment: Linux, systemd user manager, Node 26.12.1.
Surface: real T3 Code CLI/server, launched by a real systemd user unit.
Both checkouts have their own installed dependencies and fresh synthetic T3 homes.
No live database, provider turn, or model is used.

Base: 1a1f9ac18ed7cfa246207884aea93e3ce06851ce
Head: 4e4328ea3b4c1368aaf40bc7a44ee49cb8541389

Reproduce:
  Install each checkout with vp i.
  python3 driver.py SCRATCH_DIRECTORY BASE_CHECKOUT HEAD_CHECKOUT
  python3 render-evidence.py SCRATCH_DIRECTORY/run-TIMESTAMP

The driver calls each checkout's renderBootServiceUnit, changes only the isolated
unit name and environment, and starts that unit with systemctl --user. The runtime
entry forwards to that checkout's real apps/server/src/bin.ts. Service state selects
0.1.9. systemd opens boot-service.log with append semantics for stdout and stderr.

Identical sequence per commit:
1. Seed boot-service.log to 17,825,792 bytes; record its inode.
2. Start service, observe 15 one-second samples.
3. Restart service, observe 15 one-second samples.
4. Append another 17,825,792 bytes of synthetic output with O_APPEND.
5. Observe 132 five-second samples without restarting (about 11 minutes).
6. Stop service and record the final size to check output still reaches the inode.

Timing labels are measured elapsed seconds; rendering overhead adds a little time.
Videos are time-lapses of the captured systemd/filesystem transcript, not browser
or desktop screen recordings. One frame per measured sample, at two frames/sec.
Static captures show the last running sample. Source measurements are also supplied.

The driver's /api/health probe is not a T3 endpoint: without a web bundle, that
fallback returns 503. It is omitted from the rendered evidence to avoid confusing
it with server health. Separate readiness evidence uses the actual public
/.well-known/t3/environment endpoint (HTTP 200 on both runs) and checks only the
safe 'T3 Code server is ready.' log marker. Raw logs and discovery response bodies
are private and are not uploaded, because they contain credentials or identities.

No automated test result is used as evidence. No application source was changed.
AI-assisted; verified with the tests and tools listed above.