break: file reads in K8s charm unit tests

[dwilding]

The claim

How to manage files in the workload container — Write unit tests states, in the context of a host-mounted file (testing.Mount with a source on the host):

If the charm writes to /etc/myapp/backup.yaml in the container while handling the event, backup_file.read_text() will return the data that the charm wrote.

This asserts that writes performed by the charm inside the container propagate back to the host file backing the mount.

What this PR does

It adds a targeted refutation attempt to the kepler charm:

• An update-backup action that writes to /etc/myapp/backup.yaml using the docs' recommended library (charmlibs-pathops ContainerPath), following a common, realistic pattern: remove the existing file, then write fresh contents (unlink(missing_ok=True) then write_text(data)).
• A unit test (test_update_backup_writes_through_mount) that mounts a host file at /etc/myapp/backup.yaml, runs the action, and asserts the host file now contains the new data.

What the failing test proves

tox -e unit fails on the new test: after the charm wrote updated: data\n to the mounted path, the host file still contained the original data.

Under the hood, ops testing implements a Mount as a symlink from the container's simulated filesystem to the host source. An in-place write (open-for-write through the symlink) does propagate to the host. But a write that replaces the file — such as unlink then write_text/push — removes the symlink from the container root and creates a fresh regular file there, leaving the host file untouched.

So the claim is not universally true: it holds for in-place writes but fails for write patterns that replace the file, which is a legitimate and common way a charm might "write to" a path. The doc's blanket statement should be qualified (e.g., "writes that modify the file in place" rather than "writes to").

tox -e lint passes; the pre-existing test_pebble_layer test still passes.

---

Original task for the agent:

Review the selected claim and the surrounding context. I would like you to devise an attempt to refute this claim. Your refutal attempt must take the form of changes to one of the stored charms (I recommend kepler) and its unit tests. Make sure the changes are targeted and constrained to your refutal attempt - your changes will need to be reviewable by a human in a PR (as a second pair of eyes on your attempt). Before you commit your changes, run tox -e lint. Then run tox -e unit, which should tell you the outcome of your attempt. Report back to me.

Model: Z.ai GLM 5.2