fix: lazily create APRSDClient in APRSDFilterThread

[hemna]

Summary

APRSDFilterThread.__init__ eagerly constructs APRSDClient(), which raises MissingConfigOptionException whenever the aprs_network driver is enabled (the default) but callsign/password/host are not configured. This made it impossible to construct filter-thread subclasses in unconfigured/test environments even when the subclass never decodes packets.

Impact

Broke third-party plugin test suites and construction when these are installed:

• aprsd-mqtt-plugin (MQTTRawPlugin extends APRSDFilterThread; its loop() never uses the client) — 3 tests failed
• aprsd-webchat-extension (WebChatProcessPacketThread extends APRSDProcessPacketThread) — 2 tests failed

Both suites pass on aprsd 4.2.4; both fail on master, so this is a regression from commit 274d5af (in 4.3.0/5.0.0/5.0.1, none of which have been released to PyPI yet — 4.2.4 is still the latest published version). It will reach users for the first time with the 5.x release.

Fix

Create the client lazily in loop() (if not self._client: self._client = APRSDClient()), matching the existing APRSDRXThread pattern. Construction no longer requires a configured connection.

Tests

• New regression test test_constructor_without_client in tests/threads/test_rx.py
• aprsd suite: 783 passed
• aprsd-mqtt-plugin: 14 passed (was 3 failed)
• aprsd-webchat-extension: 73 passed (was 2 failed)
• ruff clean