Add missing symbols to the Debian mailutils package's .symbols file

dh_makeshlibs/dpkg-gensymbols failed the Trixie build: neither the
body.c patch's exports nor the new envelope-recipient accessors were
ever added to debian/libmailutils9t64.symbols, so both surfaced
together the first time the build actually completed dh_makeshlibs
against the patched source. Fixed by extending 0002-debian-trixie.patch
with the missing entries, each tagged 1:3.19-1+bongo1 (matching
dpkg-gensymbols' own suggestion) since none of these symbols exist in
any unpatched Debian mailutils build.

Verified with a full dpkg-buildpackage in a fresh Debian Trixie Docker
container against the real pinned source, not just a symbols-file diff.

docs/test-evidence/0.7-r1.md

@@ -572,6 +572,43 @@ matching the Gentoo overlay fix; see SIEVE-04's update) was also added to
 the build in the same window. Both are now part of the standard
 `contrib/debian/build-trixie-bundle.sh` run.
 
+### Update, 2026-08-01: `dh_makeshlibs` rejected the new public symbols
+
+Adding `mu_envelope_set_recipient()` and friends (SIEVE-04's "to" update)
+to `libmailutils` gave the Trixie build a real, reported failure:
+`dh_makeshlibs`/`dpkg-gensymbols` compares the freshly built
+`.so`'s exported symbols against the tracked
+`debian/libmailutils9t64.symbols` file and fails the build if any are
+missing, precisely so reverse-dependencies get correctly versioned
+`Depends:` bounds. Neither the earlier `body.c` patch's exports
+(`sieve_test_body`, `mu_i_sv_body_req_args`, `mu_i_sv_body_tag_groups`)
+nor the new recipient accessors
+(`mu_envelope_get_recipient`/`sget_recipient`/`aget_recipient`/
+`set_recipient`) were ever added to that file, so both sets of new
+symbols surfaced together the first time `dh_makeshlibs` actually ran to
+completion against this patched source.
+
+Fixed by extending `0002-debian-trixie.patch` (the patch that already
+carries this rebuild's `debian/`-internal changes, applied directly with
+`patch -p1` rather than through quilt, matching its existing convention
+for packaging-metadata edits) with a hunk adding all seven symbols,
+each tagged `1:3.19-1+bongo1` -- the exact version string
+`dpkg-gensymbols`' own diff output recommended, and the only value that
+is actually correct here: unlike the surrounding `1:3.17` entries (the
+real upstream version that introduced them), these symbols do not exist
+in any unpatched Debian mailutils build, so tagging them with a bare
+upstream version would incorrectly claim they do.
+
+Verified by actually completing the build this failed at, not just
+re-diffing the symbols file: a fresh Debian Trixie Docker container,
+the exact pinned `mailutils_3.19` source (SHA-256-verified against the
+build script's own checksums), all four current patches applied through
+the real `quilt push -a`/`quilt refresh` sequence
+`build-trixie-bundle.sh` uses, build dependencies installed via
+`mk-build-deps`, and a full `dpkg-buildpackage -us -uc -b` -- which
+completed successfully and produced the expected `.deb` set, with
+`dh_makeshlibs` raising no "new symbols appeared" error this time.
+
 ## BLD-16
 
 Result: **PASS**