Bound PartitionInfo snapshot buffers via config_node_snapshot_buffer_size_max

[CRZbulabula]

Problem

Taking a ConfigNode snapshot always allocated a fixed 32MB heap buffer (PARTITION_TABLE_BUFFER_SIZE hard-coded in PartitionInfo), regardless of the actual partition table size. On edge deployments the default heap is only 224MB and ConfigNode snapshots are triggered frequently, so the fixed allocation can cause GC spikes when the partition table is small.

Changes

• Add SnapshotStreamFactory + ReusableBufferedOutputStream (node-commons) providing capped and reusable buffered streams for snapshot files. The buffer size is bounded by the new config_node_snapshot_buffer_size_max parameter (default 4MB; 0 disables buffering), and write buffers are pooled per thread via ThreadLocal + SoftReference.
• PartitionInfo: replace the fixed 32MB buffer with the factory. The read buffer is sized from the file size and capped by the parameter, and the write buffer is capped and reused across snapshots on the same thread.
• Edge distribution: config_node_snapshot_buffer_size_max=8192, documented in iotdb-system.properties.template.
• Scope is confined to PartitionInfo: no other snapshot code paths are changed.

Tests

• New SnapshotStreamFactoryTest (buffer cap, disabled-buffering passthrough, round-trip with buffer wrap-around, large-write bypass, buffer reuse, idempotent close).
• New ConfigNodeConfigTest (default alignment with the factory cap, setter validation).
• PartitionInfoTest runs all snapshot round-trips with a 64KB buffer cap, including a snapshot larger than the write buffer.

[JackieTien97]

Requesting changes because the new stream-based template snapshot recovery regresses an accepted vector-schema form. The remaining inline comments cover a low-priority buffer-cap contract issue and cleanup/documentation items.