Bound logLines and reset it on deactivate

[Chirag6722]

Fixes #5, per your direction: ring buffer plus a reset in deactivate().

logLines had no ceiling, in a codebase that caps everything else it retains: history has truthlog.maxEntries, output has truthlog.maxOutputBytes, this had nothing. One line per recorded command means it grows for as long as the window stays open.

It was also module state that deactivate() left alone while clearing outputChannel. Across a deactivate/activate cycle in the same extension host, a new session starts holding the previous session's lines, and getLogLines() hands the tests both sessions mixed together.

Capped at 5000 lines, oldest dropped first, cleared on deactivate. The OutputChannel is untouched and still holds the full log, which is what a user actually reads; this array exists only because VS Code gives no way to read a channel back.

One thing worth a look in review. The trimming lives in an exported appendBounded() and the tests drive that against a local array, rather than driving log() itself. That is not squeamishness about a wide test API, it is a hazard I hit while writing it: cmdExeDetection and the activation suite read getLogLines() by recording an offset and slicing from it. Pushing thousands of lines through the shared buffer to reach the cap shifts those offsets, and once the buffer is full, an offset captured earlier points past the end, so slice(before) silently returns [] and the assertion fails for a reason unrelated to what it is testing. Testing the helper directly avoids putting that trap in the suite for whoever adds the next log-reading test.