[Security Solution][Attacks/Alerts] Add a scheduled attack icon (#17461)

[e40pud]

Summary

Closes https://github.com/elastic/security-team/issues/17461

This PR introduces a "scheduled" icon to the Attack Group component within the Attacks table and the Attack Discovery page. Clicking this icon opens the schedule details flyout.

Key Changes:

• Reusable Component: Extracted the scheduled icon button into a new, reusable ScheduleDetailsButton component with its own translations.
• UI Integration: Integrated the new button into the AttackGroupContent (Attacks table) and Title (Attack Discovery panel header) components.
• Accessibility & UX: Wrapped the button in an EuiToolTip for sighted users, added proper aria-labels, and stopped event propagation on click to prevent unintentionally expanding the attack group details row.
• Telemetry: Added tracking for when the schedule details flyout is opened (AttacksEventTypes.ScheduleDetailsFlyoutOpened) with sources attacks_page_table and attack_discovery_page.
• Testing: Added and updated Jest unit tests to cover the new component and telemetry. Updated Scout E2E tests (attacks_page_smoke.spec.ts and attacks_schedule.spec.ts) to verify the button and flyout visibility.

Verification Steps

1. Navigate to the Attacks page or the Attack Discovery page in the Security Solution.
2. Ensure you have at least one scheduled attack discovery.
3. Verify that a calendar icon appears next to the title for scheduled attacks.
4. Hover over the calendar icon and verify the tooltip "Scheduled Attack discovery" appears.
5. Click the calendar icon:
   • Verify that the Schedule details flyout opens on the right side.
   • Verify that the attack group details row does not expand (event propagation is correctly stopped).
6. Check the network tab or telemetry logs to verify the AttacksEventTypes.ScheduleDetailsFlyoutOpened event is fired with the correct source (attacks_page_table or attack_discovery_page).

Screenshots

---

PR developed with Cursor + Gemini 3.1 Pro

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-solution (Team: SecuritySolution)

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

[kibanamachine]

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#12538

[✅] x-pack/solutions/security/plugins/security_solution/test/scout_security_attacks_alignment/ui/parallel.playwright.config.ts (--arch stateful --domain classic): 50/50 tests passed.
[✅] x-pack/solutions/security/plugins/security_solution/test/scout_security_attacks_alignment/ui/parallel.playwright.config.ts (--arch serverless --domain security_complete): 50/50 tests passed.

see run history

[MadameSheema]

Follow-up: loginAsAdmin() grants full admin privileges, which is broader than what these tests actually need. The Scout Security Solution convention is to use the least-privileged role — browserAuth.loginAsPlatformEngineer() is the right default for standard CRUD access on the Attacks page.

This isn't introduced by this PR so I'm not blocking on it, but since you're already touching these specs it would be a good time to swap it :)

[MadameSheema]

This is semantically equivalent to .first(), which playwright/no-nth-methods targets. Since the test always seeds exactly one attack and tableScheduleButtons is already scoped to attacksTableSection, the locator should resolve to a single element — which means await this.tableScheduleButtons.click() would work directly and Playwright's strict mode would enforce uniqueness. The .all() destructure adds complexity without benefit here.

The same issue exists in the pre-existing openFirstAttackDetailsFromTable() method — but since you're adding a new method, it's worth getting right rather than copying the pattern.

[e40pud]

I agree that .click() would work with Playwright's strict mode right now since we only seed one attack. However, in an upcoming PR, I will be extending the seeding to add multiple attacks to the table. I've left the .all() destructuring pattern in place to future-proof these methods so they don't break when multiple buttons are present.

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: d897289
• Build duration: 67 mins

Failed CI Steps

• FTR Configs #156

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	9585	9586	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	12.1MB	12.1MB	+639.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	159.8KB	160.0KB	+230.0B

History

• 💛 Build #450659 was flaky 24fb94a
• 💛 Build #450656 was flaky 49a98ad
• 💛 Build #450264 was flaky d68bb55
• 💔 Build #450185 failed 3d0a64a
• 💔 Build #450173 failed 60503ef

cc @e40pud

[e40pud]

Follow-up: loginAsAdmin() grants full admin privileges, which is broader than what these tests actually need. The Scout Security Solution convention is to use the least-privileged role — browserAuth.loginAsPlatformEngineer() is the right default for standard CRUD access on the Attacks page.

This isn't introduced by this PR so I'm not blocking on it, but since you're already touching these specs it would be a good time to swap it :)

I completely agree that we should be using the least-privileged role (browserAuth.loginAsPlatformEngineer()) here. I actually tried swapping it during development, but it caused some unexpected test failures (it seemed the platform engineer role couldn't see the seeded attacks, causing the locators to fail).

Since figuring out the exact privilege gap or setup issue might take a bit of digging, I've created a follow-up ticket to address this specifically so it doesn't block this feature delivery: https://github.com/elastic/security-team/issues/17653. We'll get this swapped over in that PR!