docs: design custom metrics collection path for node-level resource monitoring

[Copilot]

The issue investigated whether Pullpiri's MonitoringServer could collect application-specific custom metrics (FPS, Latency) and deliver them to PolicyManager. The result: the App→MonitoringServer→etcd path already exists via StressMonitoringMetric, but the MonitoringServer→PolicyManager forwarding link is missing.

Findings

Existing (implemented):

• SendStressMonitoringMetric gRPC RPC in MonitoringServerConnection with JSON payload supporting fps, latency, cpu_loads
• process_stress_requests() loop in manager persists to etcd at /pullpiri/metrics/stress/{process}/{pid}

Missing (gaps):

• Custom metrics never reach PolicyManager — ReportNodeMetricsRequest only carries NodeInfo
• PolicyManager has no custom metric threshold evaluation
• No REST endpoint in SettingsService to query custom metrics

Design Documents Added

doc/architecture/EN/LLD/custom_metrics.md and doc/architecture/KR/LLD/custom_metrics.md cover:

• Gap analysis table mapping each path segment to its implementation status
• Two design options for completing the MonitoringServer→PolicyManager path:
  • Option A (recommended for MVP): extend existing ReportNodeMetricsRequest with a repeated CustomMetric custom_metrics field
  • Option B (recommended long-term): add a dedicated ReportCustomMetrics RPC, decoupled from system metric cadence
• CustomMetric interface definition — process_name, container_name, metric_name, metric_unit, value, timestamp_ms
• FPS end-to-end example with proposed policy YAML structure
• SettingsService REST extension (GET /api/v1/metrics/custom) using the already-implemented get_all_stress_metrics()

Design decision points (Option A vs B, batch vs immediate, structured vs JSON payload) are left for maintainer review.