[Chore] Add nightly schedule

[weronikaolejniczak]

Summary

Closes https://github.com/elastic/eui-private/issues/718
Closes https://github.com/elastic/eui-private/issues/712

• Modified update_kibana_dependencies* workflows to support non-PR updates.
• Made update_kibana_dependencies workflow trigger based on a schedule: - cron: '0 3 * * 1-5'.
• Registered a new Slack App and Slack webhook for #eui-core channel, and added in the repo as KIBANA_NIGHTLY_SLACK_WEBHOOK. Instead of commenting on a source PR (that doesn't exist), it sends notifications in Slack.

QA instructions for reviewer

Not possible to test until merged to main.

[Copilot]

Pull request overview

Adds a scheduled (“nightly”) execution path to the Kibana dependency update / integration-test workflow chain, so it can run without an originating PR and report results via Slack.

Changes:

• Added a weekday schedule trigger to update_kibana_dependencies.yml, with logic to mark scheduled runs as nightly.
• Extended the prepare/open-PR subworkflows to support nightly runs (fixed branch reuse, PR body enrichment with EUI snapshot/changelog details).
• Added Slack notification output for nightly runs, including optional Buildkite link discovery.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/update_kibana_dependencies.yml	Adds weekday schedule trigger and nightly dispatch args to the release workflow.
.github/workflows/update_kibana_dependencies__prepare_changes.yml	Adds nightly inputs + fixed branch/force-push behavior; forwards nightly metadata to the open-PR workflow.
.github/workflows/update_kibana_dependencies__open_pr.yml	Adds nightly PR body generation (including changelog entries) and Slack webhook notification.
.github/workflows/release.yml	Passes nightly metadata (EUI ref/version/last release) into the Kibana integration workflow chain.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[weronikaolejniczak]

Concurrency also supports queue: max as per (source):

To allow more than one pending job or workflow run to wait in the same concurrency group, use the optional queue property. The queue property accepts the following values:

single (default): At most one job or workflow run can be pending in the concurrency group. When a new job or workflow run is queued, any existing pending job or workflow run in the same group is canceled and replaced.
max: Up to 100 jobs or workflow runs can be pending in the concurrency group. When the queue is full, any additional jobs or workflow runs are canceled.

The reason we're using it is because we have 3 separately dispatched workflows, so we want a FIFO queue and not a single workflow.

[mgadewoll]

🟢 LGTM, let's ship and test! 🚢

[weronikaolejniczak]

@mgadewoll ready to re-review:

• improved the changelog entries (7dc8e21) with PR number ordering (small follow up to remove all the arg parsing: 0d96e40, I had more args in the first version)
• spotted and removed an unused job output (76b7bfe)
• moved the PR status check to a bash script to DRY it out, it was like that before but since I'm updating it I might as well simplify it (a9f32b0)

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: a9f32b0
• Documentation website
• Storybook
• 🚫 Visual regression tests skipped (remove the skip-vrt label to re-enable)

cc @weronikaolejniczak

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: a9f32b0

cc @weronikaolejniczak