RFE: Provide mount API to copy content from the container. Specifically /opt content.

Some users have applications that install under /opt. Existing approaches and their trade-offs are discussed in Discussion #1038.

When /opt resolves to persistent /var/opt, whether through a symbolic link or a bind mount, its contents become persistent, user-managed state. Application content initialized there during installation is therefore not replaced during subsequent bootc switches or upgrades.

We do not want to change bootc’s contract: bootc should not modify or merge /var after installation. Doing so could overwrite user data and create ambiguous rollback behavior.

However, bootc could provide a supported mechanism for accessing selected content from the booted or staged container image. An application or administrator could then either copy that content into /var or
mount and consume it directly.

A conceptual interface might be:

bootc image mount \
--deployment booted \
--source /opt/example-agent \
--target /run/example-agent-image \
--read-only

An application-specific migration service could then copy it:

rsync -a \
/run/example-agent-image/ \
/var/opt/example-agent/

Alternatively, the image content could be mounted directly at an explicitly selected location under /var:

bootc image mount \
--deployment booted \
--source /opt/example-agent \
--target /var/subdir/example-agent-image \
--read-only

The application could use this location for its immutable binaries while keeping configuration, logs and other writable state elsewhere under /var.

This preserves the existing ownership contract:

- bootc does not merge, delete or overwrite persistent /var content.
- Image content is exposed read-only.
- The administrator explicitly selects both the source and target.
- Applications own any synchronization or migration policy.
- Rollback and persistent-state compatibility remain application decisions.

The API should define:

- Access to both booted and staged deployment content.
- Read-only enforcement.
- Whether the target must be an empty mount point.
- Mount lifetime and explicit unmount behavior.
- How the mount is recreated during boot.
- Integration with systemd service ordering.
- Behavior when the source path does not exist.
- Behavior when the original container image is no longer locally available.
- Upgrade and rollback semantics.

A possible systemd integration could look like:

[Unit]
Description=Expose image-owned agent content
Before=example-agent.service
RequiresMountsFor=/var/subdir

[Service]
Type=oneshot
ExecStart=/usr/bin/bootc image mount --deployment booted --source /opt/example-agent --target /var/subdir/example-agent-image --read-only
RemainAfterExit=yes
ExecStop=/usr/bin/bootc image unmount /var/subdir/example-agent-image

[Install]
WantedBy=multi-user.target

The goal is to make content already delivered through the bootc image accessible without:

- Automatically modifying /var.
- Pulling the same image again with Podman.
- Requiring applications to duplicate their complete payload elsewhere in the image.

Start with Discussion #1038 and the existing bootc image and deployment behavior described in this issue. Define the mount and unmount interface, lifecycle, read-only guarantees, staged-versus-booted access, systemd integration, and missing-image behavior; the work is done when these semantics are specified and implemented with appropriate coverage.

Written by the indexing model from the issue text.