exclusions support for header, banner, epic and gutter components

[AnastasiiaBalenko]

Ticket link

What does this change?

This PR replaces hardcoded banner section/date suppression with a shared, config-driven exclusions system, and applies the same exclusions behaviour across Banner, Epic, Header, and Gutter Ask.
Main changes:

• Added a new exclusions config loader from S3 with typed rule support:
  • sectionIds
  • tagIds
  • dateRange
  • contentTypes (Fronts or Articles)
• Added a shared matcher that evaluates exclusions consistently across channels.
• Updated routers so all channels check exclusions before selecting tests/rendering:
• Wired exclusions reloader into server startup and passed it into all relevant routers.
• Removed hardcoded banner-only section suppression logic and tests.
• Added missing sectionId and tagIds fields on Header targeting to align with matcher capabilities.

Behaviour notes
If no exclusions exist for a channel, behavior is unchanged.
Matching is case-insensitive for section and tag IDs.
Empty contentTypes and contentTypes containing both Fronts and Articles matches either type.

How has this change been tested?

• Added focused unit tests for the matcher covering: no rules, section matching, tag matching, date range matching, content type matching with isFront flag
• deployed to CODE env and checked that epic, banner, header, gutter ask are shown up as expected.

How can we measure success?

Have we considered potential risks?

Images

Accessibility

• Tested with screen reader
• Navigable with keyboard
• Colour contrast passed
• The change doesn't use only colour to convey meaning

[tomrf1]

I'm wondering if this file would be simpler (in particular the types) if we defined the targeting type here as e.g.

interface Targeting {
    tagIds?: string[];
    sectionId?: string;
    contentType?: string;
}

I think only epicRouter.ts would need to change how it calls inExclusions.
What do you think?

[AnastasiiaBalenko]

Yes, thanks, it really makes the function simpler! Updated