test: pin the contents kept when a symlinked .env is replaced

[Gares95]

The six existing symlink tests pass unchanged against two implementations that
behave differently, so neither behaviour is currently pinned.

When .env is a symlink and follow_symlinks is left at its default, the link
is replaced by a regular file (already asserted by
test_set_key_symlink_to_existing_file and
test_unset_key_symlink_to_existing_file), and that file keeps the contents the
path resolved to beforehand. That second half is not covered, because of how the
two tests are constructed:

• test_set_key_symlink_to_existing_file writes a target holding a=x, then
  sets the same key a. Whatever was read is overwritten by the set, so the
  prior contents cannot show up in the result. The assertion is also
  "a='y'" in symlink.read_text(), which tolerates any extra content.
• test_unset_key_symlink_to_existing_file writes a target holding only a=x,
  then unsets a. The result is "" whether the previous contents were read or
  not.

I checked this by running the existing suite against a build that discards the
previous contents instead of keeping them: all six symlink tests still pass, and
a symlinked .env whose target held three keys came back holding only the newly
set one.

This adds two tests whose targets hold a key the operation does not touch, so the
kept contents are asserted exactly:

• test_set_key_symlink_keeps_target_contents: target holds b=x, set a=y,
  result is b=x\na='y'\n.
• test_unset_key_symlink_keeps_target_contents: target holds a=x and b=y,
  unset a, result is b=y\n.

Both expected values are the current output on main, not new behaviour. No
existing test is modified and nothing in src/ changes, so this is purely
additional coverage.

They also mirror contracts the suite already pins for a regular file, so the
expectations are not new: test_set_key covers a=b\n plus setting c giving
a=b\nc='d'\n, and test_unset_with_value covers a=b\nc=d minus a giving
c=d. These two are the symlink equivalents.

For context, I opened and then withdrew #690, which changed this read path and
would have dropped those contents. The suite stayed green throughout, which is
what prompted me to look at the coverage rather than the behaviour.