Backporting commits from trunk to a versioned branch for a release should be done by a permanent committer. If a single person did most of the work on the ticket and the commit to trunk, then ideally a different person should review and do the backport.
A basic SVN flow to backport a commit could look like this:
$ svn switch '^/branches/4.7'
$ svn merge -c 12345 '^/trunk'
$ svn ci
If the fix in trunk required multiple separate commits, you can backport them all in a single command like this:
svn merge -c 10001,10002 '^/trunk'
For merges you should generally use a pristine branches/4.7 checkout that has no code changes other than what’s being merged and a test site for testing the merged commit on (which you should always do).
Also, although you’ll probably never need it, if you’re merging multiple commits one after each other, don’t forget to run svn up between them. If what you need to merge has multiple commits, also feel free to squash them down for the branch commit to make it easier for everyone reading.
Sometimes multiple changes to the same code are made in trunk before they are ported to a branch. In this case, you will get conflicts, so be sure to port the older changesets as well. Committers asking for a backport should indicate this situation on the ticket.
To add the merge info afterwards you can run svn17 merge --record-only -c 12345 '^/trunk'.
Note: Make sure to run the above commands from the branch root, and not from a sub directory. The reason for this is that the svn:mergeinfo is a SVN property on /branches/4.7 which the SVN client sets, it’s not a server side thing.
At the bottom of https://core.trac.wordpress.org/browser/branches/4.7 you see two links, ‘merged’ and ‘eligible’. The second one shouldn’t list commits which are already merged.