Stop restarting pgadmin on every lerd start

[JoeJoeflyn]

RestartIfConfigDrifted rewrote a service's preset config files unconditionally and restarted the container when the newest file was newer than the container's boot. For pgadmin the pgpass file is rewritten on every pass even when its content has not changed, so its mtime advances past the container's start and the next lerd start sees it as drifted and restarts again, looping forever.

MaterializeServiceFilesChanged already compares content and skips the rewrite when nothing differs, so the mtime does not move. Route RestartIfConfigDrifted through it and bail out early when it reports no change.

Closes #1490

[geodro]

This doesn't break the loop. MaterializeServiceFiles is already a one line wrapper around MaterializeServiceFilesChanged, so the seam swap changes nothing that gets written, and the early return never fires for pgadmin because changed comes back true on every pass.

The pgpass mount is mode 0600 with chown true. Podman's :U re-owns it to a userns mapped uid on container start, so the host user can't read it back afterwards. The content compare does an os.ReadFile, gets EACCES, and drops through to the unlink and rewrite branch, which sets changed. On my install the file is owned by 105049 at 0600 and cat gives permission denied, and re-materialising over it moves the mtime every time. That's the loop, the file being unreadable rather than the content differing.

The new test can't fail. It stubs the materialise seam to return false, which is a state pgadmin never produces, so it's asserting the patch rather than the bug and would stay green on a build that still restarts every start.

Separately, the early return costs something even where it works. The mtime is the durable signal, changed isn't. Rewrite a file, have the restart fail, and the next pass now bails before the mtime check ever runs, so the container keeps serving stale config forever.

Whatever fixes this has to compare against something we can still read after podman takes the file, so probably a sidecar holding a hash of the last rendered content, compared to the freshly rendered bytes.