feat: Add CloudWatch alarm browser and triage entry flow

[YoungJinJung]

Summary

Add a CloudWatch alarm browser to unic so operators can use alarm state as the incident entry point before drilling into logs, related resources, or the dedicated metrics viewer.

Why

unic already supports CloudWatch Logs, but real AWS incident response usually starts from alarm state, recent transitions, and the question of which resource is currently unhealthy. Operators need to answer "what is broken right now?" before opening raw logs.

Scope Boundary

This issue should not implement the standalone CloudWatch metrics viewer/charting flow.
That work is already tracked in:

• feat: Add CloudWatch metrics viewer with single-series chart rendering #125 single-series CloudWatch metrics viewer
• feat: Add CloudWatch metric presets and chart controls #126 metric presets and chart controls
• feat: Add CloudWatch multi-metric comparison overlays #127 multi-metric comparison overlays

#129 should focus on alarm browsing and alarm-driven triage. If a metrics viewer exists later, this issue may link or hand off to it, but it should not duplicate that implementation.

Desired behavior

• Add a CloudWatch Alarms or equivalent alarm-first feature entry in the service catalog
• Browse alarms by state: ALARM, OK, INSUFFICIENT_DATA
• Show recent state transitions and timestamps
• Drill into alarm details, dimensions, and related resources
• Make it easy to jump from an alarm into logs or the related resource flow
• Optionally link into the separate metrics viewer once #125-#127 land

Initial scope

• CloudWatch alarm list
• Alarm detail view
• Recent state transition history
• Resource-centric drill-down where the alarm dimensions map cleanly to flows already supported by unic
  • ECS services/tasks
  • RDS instances
  • EC2 instances
• Log drill-down where a related log target is obvious
• ALB / target groups later if a separate issue lands first

Acceptance Criteria

• Operators can open alarms without leaving unic
• Alarm states and recent transitions are visible in the TUI
• At least one drill-down path exists from alarm -> related resource or logs
• Metrics rendering/chart controls are explicitly out of scope for this issue
• Tests cover message/update flows and repository behavior
• README and docs are updated