mysql is locked; can't kill query
The commenter was correct -- your kill query 77 was killing your own thread's query... as was indicated by the fact that the row from the processlist indicated that thread 77 (you) was the thread that was currently running the SHOW FULL PROCESSLIST command.
The way you fix your problem is by finding the step you took before running mysqldump, and undoing it.  This does not appear to be a MySQL issue.
From the Mediawiki Manual: Backing Up a Wiki...

Mysqldump from the command line
The most convenient way to create a dump file of the database you want to back up is to use the standard MySQL dump tool mysqldump from the command line. Be sure to get the parameters right or you may have difficulty restoring the database.
First insert the following line into LocalSettings.php
$wgReadOnly = 'Dumping Database, Access will be restored shortly';
this can be removed as soon as the dump is completed.

Your database isn't locked... your wiki is locked, because you locked it before you ran the backup.
If the $wgReadOnly variable in Mediawiki's LocalSettings.php configuration file is set, this locks the wiki against writes and offers the message you put in the string as an explanation to users of the wiki.
This suggests that you added this line while reading the Mediawiki docs but did not remove the line when you were done with the backup, unrelated to mysqldump or MySQL.  When mysqldump (or any other client) disconnects, it is impossible for locks to linger even accidentally inside MySQL because locks can only be held as long as the session/thread holding the locks is still connected.
If your wiki isn't massive, and having your wiki become briefly unresponsive while the dump is running isn't a problem, then you don't need to lock the wiki at all.  I have a scheduled job that runs against the MySQL server that runs my Mediawiki installation and I don't lock the wiki to take backups.  If your wiki is mission-critical and you want zero potential disruption, you could also set up a MySQL replication slave and make backups against the slave instead of the master.  If your server has the resources for it, you could run the slave on the same machine as the master, on a different port other than the default 3306.