fix(hosting): bound part_log, cap query threads

part_log was not implicated in either report behind this change and is not on ClickHouse's sub-16GB disable list, but it is the merge history you need to diagnose the next occurrence. Measured at 0.18 KiB per part event under insert churn - 10x cheaper than text_log over the same window - so a TTL bounds it rather than removing it.

max_threads is the one sub-16GB recommendation the stack was still missing: it resolved to auto(4) and queries really did use 4 threads, so concurrent_threads_soft_limit_num was not covering it.

hosting/docker/clickhouse/override.xml

@@ -13,7 +13,6 @@
     <!-- ClickHouse's own telemetry, too heavy for the recommended machine size -->
     <metric_log remove="1"/>
     <asynchronous_metric_log remove="1"/>
-    <part_log remove="1"/>
     <trace_log remove="1"/>
     <query_thread_log remove="1"/>
     <session_log remove="1"/>
@@ -28,6 +27,9 @@
     <query_views_log remove="1"/>
 
     <!-- A config-level ttl survives log-table recreation, unlike ALTER ... MODIFY TTL -->
+    <part_log>
+        <ttl>event_date + INTERVAL 7 DAY DELETE</ttl>
+    </part_log>
     <query_log>
         <ttl>event_date + INTERVAL 7 DAY DELETE</ttl>
     </query_log>

hosting/docker/clickhouse/users-override.xml

@@ -1,6 +1,7 @@
 <clickhouse>
     <profiles>
         <default>
+            <max_threads>1</max_threads>
             <max_block_size>8192</max_block_size>
             <max_download_threads>1</max_download_threads>
             <input_format_parallel_parsing>0</input_format_parallel_parsing>