Expose more of the lading_capture interface and add parquet rotation support

[scottopell]

• feat(observer): Expose observer module as public API
• Add documentation to public observer APIs
• docs: Add missing doc comments for public modules
• feat(capture): add file rotation support for Parquet format

[scottopell]

Sub-second metric resolution limitation discovered

While working on fine-grained-monitor, I discovered that lading-capture has a hardcoded 1-second tick duration that prevents sub-second metric resolution:

Root cause:

• lading_capture/src/manager/state_machine.rs:31: pub(crate) const TICK_DURATION_MS: u128 = 1_000;
• lading_capture/src/manager.rs:36: const TICK_DURATION_MS: u128 = 1_000;

Impact:

• All metric samples within the same second are bucketed into one tick
• Timestamps are calculated as: start_ms + (tick * 1000)
• For gauges, only the last sample per second is preserved
• Sub-second sampling (e.g., 250ms/4Hz) collects data but loses timestamp granularity

Use case:
For fine-grained-monitor, we wanted 4Hz sampling to detect short-lived containers (~500ms lifetime, e.g., OOM-killed pods). Per Nyquist-Shannon, 4Hz sampling should capture these events, but the 1-second tick bucketing defeats this purpose.

Potential fix:
Make TICK_DURATION_MS configurable, either via:

1. A constructor parameter to CaptureManager
2. A generic const parameter on StateMachine/Accumulator

This is not urgent for the current PR, but documenting here for future reference. I have added a validation in fine-grained-monitor that fatally crashes if --interval-ms is set to anything other than 1000ms, with a descriptive error message pointing to this limitation.