Rewrite `notify-slack` lambda function

### Context

The current Lambda function responsible for reporting system errors to Slack and OpsGenie has grown organically and is becoming increasingly difficult to maintain. The codebase feels messy, lacks clear structure, and may contain hidden or unknown bugs.

This makes it harder to safely evolve the system and increases the risk of regressions when introducing changes.

---

### Objectives

This task aims to improve the reliability, maintainability, and clarity of the error reporting mechanism by:

* Refactoring the Lambda codebase to improve structure and readability
* Reducing potential hidden bugs through clearer logic and separation of concerns
* Making the system easier to extend in the future

---

### Proposed Improvements

#### 1. Strengthen TypeScript Usage

* Introduce stricter typing across the codebase
* Define clear interfaces/types for:

* Incoming log events
* Parsed log structures
* Outgoing payloads (Slack, OpsGenie)
* Reduce reliance on loosely typed or `any`-based logic

#### 2. Improve Test Coverage

* Add unit tests for core logic (parsing, filtering, routing)
* Ensure edge cases are covered (malformed logs, network failures, etc.)
* Mock external integrations (Slack, OpsGenie)

#### 3. Standardize Log Structure

* Define a common log format to be used across all projects
* Ensure logs are:

* Easy to parse
* Consistent across services
* Strongly typed via a shared TypeScript interface
* Consider creating a shared package or schema for reuse

---

### Expected Outcome

* A cleaner, more maintainable Lambda function
* Improved confidence in the system through better test coverage
* A standardized logging structure that can be reused across projects
* Easier onboarding and debugging for developers

---

### Notes

This refactor is a good opportunity to step back and rethink how logs are structured and consumed across our ecosystem, rather than only addressing the Lambda in isolation.