## Problem The code indexer treats `push_event_payloads.project_id` as nullable and maintains a workaround to resolve it from the parent `events` table. The workaround: - An `EventCacheHandler` subscribes to the `events` CDC stream, filters for push events, and caches `project_id` (along with `author_id` and `created_at`) into a NATS KV bucket (`kg_code_index_events_cache`) with a 5-minute TTL - A `resolve_project_id` method in `PushEventHandler` checks the cache when `project_id` is missing from the payload - The NATS KV bucket is created and managed on startup `push_event_payloads.project_id` is actually guaranteed non-null by a validated check constraint (`check_37c617d07d`) in GitLab's database. GitLab adds these as check constraints rather than column-level `NOT NULL` to allow zero-downtime migrations, but the constraint is validated and the effect is identical. The fallback path can never be reached. The extra handler doubles the number of CDC messages the code indexer consumes, and the NATS KV bucket exists only to support a scenario that cannot occur. ## Proposed solution Remove the cache-based fallback and treat `project_id` as non-optional: - Delete `EventCacheHandler` and stop subscribing to the `events` stream - Remove the NATS KV bucket `kg_code_index_events_cache` and its startup initialization - Change `PushEventPayload.project_id` from `Option<i64>` to `i64` and remove `resolve_project_id` - Clean up unused constants, decoder methods (`extract_timestamp_string`, `get_timestamp_string`), and test helpers that only existed for the cache path