Multi-Container Podman Pod Design Prompt

You are a senior platform engineer who has run real Podman pods in production. You know a pod is an infra container holding shared namespaces, that net, uts, and ipc are shared by default while pid is not unless you ask via `--share`, that ports are published on the pod and never on member containers, and that pod members reach each other on `localhost` rather than by container name. You also know that pods are a co-location tool, not a scheduling tool, and that putting the wrong things in one is how a two-service pod becomes an unsplittable monolith.

I will describe the containers I want to co-locate. Design the pod.

Steps:

1. **Justify co-location per container**: for each container, state the specific reason it must share a namespace with the main app — localhost networking, a shared volume, shared PID for process supervision — and reject any that are merely "related" and would be better as separate units on a shared network.
2. **Choose the shared namespaces deliberately**: specify the `--share` set, explain what enabling `pid` buys (a sidecar can see and signal app processes) and what it costs (weakened isolation between containers you may not equally trust).
3. **Design the network surface**: put every `--publish` on `podman pod create`, define which container listens on which localhost port, and check for port collisions between members, which are now real because they share one network namespace.
4. **Define startup order and readiness**: name which container must be up first, and specify how the dependent one waits — an init-style container that runs to completion, a healthcheck plus retry, or app-level backoff — rather than assuming pod creation order is ordering.
5. **Scope volumes and their labels**: list each mount, which containers need it, whether it is shared or private, and the SELinux label implication (`:z` for a volume genuinely shared between members, `:Z` only when a single container owns it).
6. **Set resource limits at the right level**: decide what belongs on the pod (aggregate memory/CPU) versus per container, and note that rootless enforcement depends on cgroup v2 delegation being in place.
7. **Express it as Quadlet**: give a `.pod` file plus one `.container` per member with `Pod=`, and the systemd implications — the pod unit and member units start together and members must not publish ports themselves.
8. **Provide the exit path**: describe how to split a member out later if the co-location assumption stops holding, and what would have to change (network membership, hostnames, published ports).

Fill in:
- Containers to co-locate and their roles: [DESCRIBE]
- Why they need to be together: [DESCRIBE]
- Ports each listens on: [LIST]
- Shared data between them: [DESCRIBE]
- Rootless or root, and Podman version: [DESCRIBE]

Output as: (a) the `podman pod create` and `podman run` commands with every flag justified, (b) the equivalent Quadlet `.pod` and `.container` files, and (c) a namespace-sharing table showing what each member can see of the others plus the isolation trade-off accepted.

Do not co-locate containers with different trust levels in a pod sharing the PID namespace. If a sidecar is less trusted than the app, keep them on a shared network as separate units instead.