Transfer DNS zones from master to slave (MS DNS to BIND9)

allow-update-forwarding { any; }; is only on the slave's reverse lookup zone, so it's gonna block attempts to update the forward lookup zone on it - that's the error message on the slave.

The master is configured to require updates to be signed with the transfer key - based on its error message, that's probably not happening since the intent seems to have been to use that key for transfers, correct?

From your description I can't tell you exactly what is the problem but I can help you rule out several things.

The cache size settings and cache ttl settings are for cached recursive query data and (as you already suspected) don't apply to authoritative data. Similarly rndc flush is inapplicable here.

Suggested troubleshooting method:

1. Verify that the notify messages are being sent by the master as expected. Check the logs and/or sniff traffic between the master and slave.
2. Verify from the logs that the notify message is being received by the slave.
3. If you cannot see the slave receiving the notify, troubleshoot as a notify issue, i.e. double-check your notify options in named.conf on the master, making sure they are defined as you expect, are not overridden later, and are scoped appropriately. I recommend using "notify explicit;" with "also-notify {slave-server;};"
4. If the slave is seeing the notify, your issue is figuring out why the zone file is not being updated as you expect. What should happen is after the notify is received, the slave should make an SOA query, compare to its current SOA, and do an AXFR (or IXFR if you have enabled it) to get the updated zone copy (assuming the SOA on the master is higher.) You should be able to observe all of this happening with a sniffer and you should also be seeing evidence of it in the logs on both servers.
5. If operations do not occur as you expect, start by manually comparing the SOA serial numbers on the two servers (dig @server $zonename SOA) to make sure you didn't accidentally give the slave a higher-than-expected serial number some time in the past which is now higher than the master's serial number.

If that doesn't work, consider posting more information, including named.conf sections from both the master and slave and logs from both servers of what is occurring after you load a freshly edited zone on the master.