Read the runtime's built-in connection-log factory instead of supplying one

Summary

• Follow-up to #398. The connection-log feature supplied its own LogFactory via WithLogFactory and injected that instance. Halibut already exposes the runtime's own per-endpoint log factory as HalibutRuntime.Logs (the default it builds and writes every connection event to) — which is exactly what Octopus's CommunicationLogFactory reads.
• Register ILogFactory as halibut.Logs and drop WithLogFactory + the parallel LogFactory. Same behaviour, one fewer moving part, and the factory the reader reads is guaranteed to be the one the runtime writes to (can't diverge). Keeps the ILogFactory injection seam so the reader stays unit-testable.

Why

Direct alignment with Octopus's proven production pattern and the most generic shape: read Halibut's built-in accessor rather than maintaining a redundant supplied factory.

Test plan

• Connection-log unit tests (reader/handler/URI) — 20/20 green (unchanged; fake ILogFactory)
• E2E Agent_ConnectionLog_RecordsRealHalibutEvents_ForPollingEndpoint re-run locally — green: a real polling RPC then reading halibut.Logs back (now with no WithLogFactory) returns non-empty, well-formed events, proving the built-in factory is the populated one
• Full solution build: 0 errors