Update the docs about Journald support.

[belimawr]

This PR updates the docs stating that journalctl is shipped in all docker image flavours, hence the Journald input from Filebeat (used by some integrations like: system, journald and iptables) can be used with any of them.

The changes on this PR need to be released together with elastic/elastic-agent#7995 and its backports.

The docs can be previewed at: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/1272/reference/fleet/install-elastic-agents#elastic-agent-basic-flavor-regular

[Copilot]

Pull Request Overview

This PR updates the documentation to clarify that all Docker image flavors now ship with journalctl, making the Journald input from Filebeat available in every case.

• Updates the basic flavor section to explicitly state the inclusion of journald dependencies.
• Removes the redundant journald dependencies note from the complete (containerized) flavor section.

Comments suppressed due to low confidence (1)

reference/fleet/install-elastic-agents.md:112

• [nitpick] The journald dependencies note has been removed from the complete flavor section. If journald support is intended to be available in containerized environments as well, please ensure that the documentation clarifies this or otherwise confirm that the removal is deliberate.

For containerized environments, the complete {{agent}} flavor is installed using the `elastic-agent-complete` command with an agent container package. This flavor includes all of the components in the servers flavor, and also includes additional dependencies to run browser monitors through Elastic Synthetics. Refer to [Synthetic monitoring via Elastic Agent and Fleet](/solutions/observability/synthetics/get-started.md) for more information.

[belimawr]

@kilfoyle this PR introduce docs that are only valid for the next release, we're adding journalctl to our docker images. What is the best what to indicate/group the docs by version?

[kilfoyle]

Suggested change

	It also includes the [journald](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) dependencies necessary to use the [journald input](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-journald.html).
	Beginning with version 9.1, the basic flavor also includes the [journald](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) dependencies necessary to use the [journald input](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-journald.html).

[kilfoyle]

this PR introduce docs that are only valid for the next release, we're adding journalctl to our docker images. What is the best what to indicate/group the docs by version?

Good question! The goal is to have different versions included in the same set of docs. When we add a new page or section that applies to a specific version, we can use these applies_to tags to indicate that. For changes that don't include a new section or page, we're supposed to mention the version right in the text, so I added Beginning with version 9.1, in your change above.

To avoid including future (say 9.1) changes in the current docs, the plan is to introduce next and current branches. That's not ready yet, however, so for now I'd say please don't merge 9.1 changes until the release goes live. I know this is inconvenient, but we will find a better approach, whether through branching, feature flags, or something else.

---

Add: I checked with another team and, for now, they're also staging their docs PRs affecting 9.1, with a plan to merge them all when the release goes live.