b) vi) Fill in your own suggestion here
My suggestion:-
Ditch F1. No more money to them if it can be helped. Ensure IP of what has been developed is handed over. Thanks but no more. (IMHO I don't think it will work out well to continue the relationship as is.)
Use AUK volunteers to get the existing code in to a more supportable state (i.e. to be able to run on the latest versions of php, whatever DB is in use, everything else). FF/FC needs not to be so critical (and I'm sure he doesn't want to be.)
Volunteers (and I will chuck my hat into the ring) continue to deal with the backend.
Transition the backend to an API style interface that the front end can use to get the data it needs to display. PHP can easily be used to return json/xml/etc, I'm not saying ditch PHP (it's not my preferred option but it works and it is there already).
Once a chunk of backend work has been done find a company to help with the front end of the site (user side first) as volunteers IME to do front end stuff rarely works well. It should be easier to create a stronger RFP once the backend is in a better state.
Various aspects of the backend need to be redesigned to cope with the way that AUK is evolving (DIYs, more GPX, ECEs, etc), this needs to be done in situ and as transparently as possible to the people dealing with the front end. API endpoints don't change as the code/DB behind them does unless necessary.
Redesign of backend needs to cope with the incomplete legacy data. It's relatively simple but I can see why a contracted company is going to claim this is harder than it is, that's where their profit margin and leverage often lies.
Any UI work requires a clear vision of what the user is expecting to see. I've no idea if that exists already. Plans for improvements (better visualisation of rides/routes/elevation, etc) needs to be considered from early on in the back end for ezample.
The backend UI (organisers/Admins) is just as important for the efficient operation of AUK, but can often be done without paid UI professionals.
I guess my main point is that there is a whole load of volunteer work that could be done on the back end (and a bit on the existing front end) that can be done before any more paid work needs to be done.
It'll probably take a load more of FF's time, but at least he knows that the person at the other end of the conversation isn't making a chunk of money each time.
To put it simply, I think the backend should be kept in house, and it needs to be rationalised by a group of volunteers (to spread the risk) before the front end is improved.
Anyway, that's my half arsed interpretation of it all. Happy to be told I'm wrong on any of it.