fix(ducklake): drain inlined data even when compaction is disabled

[adubovikov]

Problem

PR #765 added ducklake_flush_inlined_data to the CompactionService cycle so inlined data is drained to Parquet. But CompactionService was opt-in (compaction.enable defaulted to false).

That left a gap: a node that upgrades to the new inlining-off default while keeping compaction disabled never drains its legacy inline backlog. Disabling data inlining only stops new inlining — it does not flush rows inlined earlier. Those rows stay in the catalog and resident in the DuckLake extension's memory, which shows up as steadily growing RSS.

Fix

• compaction.enable now defaults to true — per-flush Parquet files and snapshots accumulate quickly, so maintenance (merge / expire / cleanup, plus the inlined-data flush) should run out of the box. Operators can still opt out explicitly.
• CompactionService now always starts, even when compaction is disabled:
  • compaction enabled -> full merge / expire / cleanup cycle (unchanged);
  • compaction disabled -> a lightweight inline-flush-only loop paced by CheckIntervalSec (first run ~1 min after startup so an existing backlog drains promptly).
• Extracted flushInlinedData(), shared by the full cycle (step 0) and the flush-only loop. It reapplies S3 client settings, holds the catalog lock (serialized with writer flushes), and is a cheap no-op once nothing is inlined.

Notes

• No new config knobs; the flush-only loop reuses the existing compaction.check_interval_sec cadence (default 3600s).

Bump 11.0.232 -> 11.0.234.

Test plan

• Fresh start with defaults: confirm the full compaction cycle runs (compaction now on by default).
• Run with explicit compaction.enable=false against a catalog that has a ducklake_inlined_data_* backlog; confirm the "Flush inlined data" maintenance log fires and the inline tables drain / RSS drops.

[CLAassistant]

All committers have signed the CLA.