fix(eol): correctly classify YELLOW (extended-support) for AWS products

[bakayolo]

Summary

Fixes a bug where the Standard and EKS schema adapters produced zero YELLOW (extended-support) findings across every adapter-driven resource type. Both adapters had stale assumptions about the endoflife.date payload shape that AWS-flavored products actually emit.

Root cause

• StandardSchemaAdapter assumed every cycle ships both support and eol. AWS ElastiCache cycles ship eol + extendedSupport (date) with no support field, so the adapter mis-derived the boundaries and never flagged the extended-support window.
• EKSSchemaAdapter still treated cycle.extendedSupport as a boolean. The current amazon-eks payload uses a date there, and cycle.eol is the end of standard support, not a true terminal date.

Fix

StandardSchemaAdapter is refactored into three explicit phases — parse → derive boundaries → classify — so the three real cycle shapes (Aurora, ElastiCache, OSS) collapse onto a single typed boundary set (standardEnd / extendedEnd / trueEOL).

EKSSchemaAdapter now reads cycle.eol as standardEnd and cycle.extendedSupport (date) as extendedEnd, while keeping the boolean fallback for legacy cycles. EKS keeps EOLDate=nil because clusters never truly stop running; past-extended-support is represented as RED via IsDeprecated && !IsExtendedSupport.

ADAPTERS.md is rewritten to catalog the three shapes the adapter now recognizes and the gotchas around AWS's missing support field.

Verification

End-to-end run via docker compose against live Wiz reports (with the EOL adapter rebuilt):

Metric	Before	After
Total findings	28,330	28,354
YELLOW	0	347
RED	4,636	4,636
GREEN	23,694	23,181
Compliance	83.64%	81.76%

Per-type YELLOW breakdown after fix: aurora-pg 25, aurora-mysql 9, eks 123, elasticache-redis 138, opensearch 23, rds-mysql 7, rds-pg 22.

Blockcell dashboard refreshed: https://blockcell.sqprod.co/sites/version-guard-dashboard/

Tests

• go test ./pkg/eol/endoflife/... — all green; adapters_test.go extended with table tests covering all three Standard cycle shapes plus EKS date/boolean variants.
• golangci-lint run — clean.
• make build + docker-compose end-to-end against live Wiz — green.

[nandiheath]

One substantive issue in EKSSchemaAdapter.classifyEKS:

case standardEnd != nil && now.After(*standardEnd):
    lifecycle.IsSupported = true
    lifecycle.IsExtendedSupport = true
    lifecycle.IsDeprecated = true

This branch fires whenever standardEnd is past, regardless of whether extendedEnd is set. If cycle.extendedSupport is absent, false, or unparseable, parseEKSExtendedEnd returns nil, and a version past cycle.eol will then be classified as IsExtendedSupport=true, IsSupported=true indefinitely — there is no terminal date to ever flip it to RED.

Suggested guard: require extendedEnd != nil && now.Before(*extendedEnd) before marking IsExtendedSupport=true; otherwise (past standard support with no known extended-support window) classify as IsDeprecated=true, IsSupported=false, IsExtendedSupport=false (with EOLDate still nil per the EKS contract).

Worth adding a table-test row for extendedSupport: false and for extendedSupport omitted, both with cycle.eol in the past, asserting IsExtendedSupport=false. The current LegacyBooleanExtendedSupport test only covers the true case, where parseEKSExtendedEnd falls back to standardEnd and the first branch correctly fires.

Minor secondary note: in the Aurora pattern (support + eol + extendedSupport all present), cycle.eol is silently ignored once support is set. That matches current upstream data where support == eol, but the assumption is unguarded — if upstream ever ships support != eol for an Aurora-shaped cycle, the divergence will be invisible. Not a blocker, just worth a comment in deriveBoundaries or a sanity assertion.

Outside those, the three-shape refactor and reordering of the classify branches look correct and the new AWS-pattern tests pin the right behavior.