fix: initialise StreamBase::lock_fd to -1

[connortechnology]

Split out of the investigation in #5029. Independent of #5033 and #5034.

StreamBase::lock_fd was initialised to 0, but every other use in the class treats a negative value as "no lock held" — openComms() sets it to -1 when open() or flock() fails, and closeComms() guards on lock_fd >= 0 before closing.

The constructor's 0 passes that guard, so a StreamBase destructed without openComms() having succeeded calls close(0) and closes stdin.

Reaching it takes connkey > 0 plus a runStream() that returns before openComms(), and MonitorStream::runStream() has two such returns: the STREAM_SINGLE branch and the !monitor branch. mode=single URLs still carry a connkey, so both are reachable in normal operation.

Severity, honestly: low today. zms exits shortly afterwards and does little in between. But it is closing a descriptor the class doesn't own, and once fd 0 is free the next open() in the process silently lands on it — the kind of thing that turns into a confusing bug later rather than now.

Adds a regression test with a minimal concrete StreamBase so the base constructor and destructor can run without a monitor, database, or shared memory. It saves and restores fd 0, so if it ever fails it reports one section rather than cascading into unrelated tests in the shared binary.

Testing: verified the test fails with lock_fd(0) restored and passes with the fix. Full suite: 117 test cases, 1788 assertions, all passing (Debug, BUILD_TEST_SUITE=ON). Note zm_font needs to run with tests/ as cwd — it uses relative data/fonts/ paths — which is a pre-existing quirk, not related to this change.