In the build directory, meson sets RUNPATH in the binaries so they can be used from the build directory, but removes RUNPATH when installing, because that allows the OS to use its standard rules to find libraries.
You probably want to set the LD_LIBRARY_PATH environment variable to tell the dynamic linker to search for libraries in your install directory.
It seems to me then that the gtk-based binaries that I will build (in due course) will need to be run in an environment where LD_LIBRARY_PATH has been set (do I understand you correctly?). This doesn’t seem like a step forward. With autotools I use xxx_LIBADD so that the installed library is correctly linked. This can, of course, be overridden using LD_LIBRARY_PATH, but I don’t need to.
You are combining two different concepts: linking, and the library search path
All of your examples are linked correctly. What they are linked to is shown on the left-hand side of the ldd output. If they didn’t link correctly, you should get an error message during compilation.
For the library search path - for installed software, you’ll usually want the libraries to be installed somewhere like /usr/lib or /usr/local/lib, and the OS’s dynamic linker knows to search in those locations. LD_LIBRARY_PATH can be used to override that temporarily or for testing purposes, which sounds like what you would want if you are running software out of your home $HOME/gtk.
Setting RUNPATH, embedding the search path into the binary, is another option if neither the default OS paths or LD_LIBRARY_PATH will work. I think to set that with meson, you’d have to modify the build file.