Writing an unstripped image via mtd would write beyond the end of the firmware partition, the only thing that's located there would be the 64 KB ART partition, containing device specific (unique) wifi calibration data (u-boot is 128 KB, plus a little for the TP-Link header in front of it). If the router 'succeeded' in writing the oversized image, the ART partition would be overwritten with garbage and non-recoverable (all wifi functionality bricked permanently), obviously the router itself wouldn't be able to boot the kernel either (garbage in the beginning of the firmware partition, ending up in a watchdog invoked reboot loop). Bootloader and bootloader environment, and with that the ability to recover via push-button tftp recovery should remain unaffected, enough to restore the router back to normal operations (but most likely without wireless capabilities, those are likely to be gone for good).
As you mentioned, trying to recover via tftp is worth trying - and according to your report of how you bricked your device, should be successful (again, ignoring the wireless state). You can significantly improve your chances of success by putting an unmanaged switch between router and your computer offering tftp services, as this avoids the delay of link training while rebooting the router (the tftp window is rather short, if the router can't find the tftpd within that time span, it stops trying before the ethernet link could be (re-)established). Make sure to use the correct IP addresses as indicated in your router's device page and temporarily disable any firewalls that might prevent the tftpd from working (you can test that with a tftp client on another computer in your network). I do suggest to ramp up the logging verbosity of your tftpd to see what the router requests from your tftpd. Personally, I do also run wireshark on the computer, if I need to debug the recovery.
Push-button tftp recovery tends to work reliably on these devices, so assuming you have followed the guides to the letter, it really should work and 'can't' go wrong (keep an eye on tftpd's logs and eventually wireshark for further hints, especially if the file is being transferred). If tftp fails, things don't look good - yes, serial access can give you an idea what's happening and widens the options of recovery a little, but serial console access still requires a functional bootloader to be in place. If the bootloader is shot as well, you'd need to recover externally with an spi writer.
A 3.3V usb2serial adapter usually goes for <1.50 EUR/ USD with slow shipping from China - or around 5 EUR/ USD from a local seller with 1-2 days delivery times. If you have a RaspberryPi, you can use that as well.
spi-writers (next escalation step beyond serial console access) with SOIC8 clamps tends to sell for ~10-20 EUR/ USD.
Soldering iron and equipment (vacuum pump, solder wick, soldering tin/ flux, soldering iron), which might be needed for either of the options above, will set you back at least 20-30 EUR/ USD.
Which of these options above are economically feasible is hard to define, it depends a lot on which of those components you already have (or can re-use in the future), just as well your experience. I'd first spend more efforts on trying to work with the purely software based push-button tftp recovery methods, before spending any money - just because the push-button tftp recovery should always work on the archer c7, if it fails (in the sense of not even requesting the file via tftp and not just rejecting it after downloading), chances for recovery via serial are close to non-existent (you'd then need to re-write the NOR flash externally). On top of that, permanent wireless damage is looming over your device anyways, so even after a successful recovery (be it via tftp, serial console or external spi-nor flasher) you might end up with a device without any remaining wireless capabilities.