There's two parts to this question:
First, can you use the Failover Partner connection string tip with AlwaysOn Availability Groups? No. AlwaysOn AG's "Listener" technology is the replacement. Have your connection strings point to the listener name and they'll always get the primary replica. (For the next part of this answer, I'm assuming you're using the listener name - if you're not, start, heh.)
Second, why do some queries fail to connect to the listener? This has to do with the number of DNS entries for the listener. All possible subnets for the listener will be in DNS at all times. If you've got a listener in 192.168.1.X and another in 192.168.100.x, both listeners will always be in DNS. By default, your clients will try connecting to each of the DNS entries serially, and not always in numeric order. If you've got a 30-second connection timeout, it's possible that your app will only try one of the IPs and then fail before it has the time to try the second one.
If you want to try connecting to all possible IPs simultaneously, check out the MultiSubnetFailover = True options for the SQL Server client as described here: http://msdn.microsoft.com/en-us/library/hh205662.aspx
Otherwise, you'll need to increase your connection timeout to account for the multiple IPs.
Update Feb 27: the question added, "I was therefore trying to come up with a way to avoid manual intervention for these (replicated) DBs should a failure of the replica occur and the other databases which are part of an AG failover."
Ooo, unfortunately, no, if the databases aren't part of the Availability Group, you're going to be doing manual work in order to fail over. One popular option is to use a DNS record, and just repoint the DNS record at whatever server is currently hosting the primary copy of the databases.
Best Answer
Hopefully that's using sys.fn_hadr_is_primary_replica in the job/jobstep and not actually enabling and disabling jobs.
You are correct. Job history is stored in MSDB which is a system database, by default on SQL Server 2017 and below system databases cannot be part of an availability group. This means the job history will only be local.
The only way, currently, to change that is to either write your own code to insert the job history into a user database (such as a dba tools database) or run the jobs from their own independent job server (which may be some enterprise job scheduler). There is nothing built in to do this automatically.
I would suggest building your own job logging table and writing the necessary logging as part of the jobsteps in each job so that you can know. This isn't just an AG thing, it's a where should I start and stop my jobs based on what I've already done thing and that's the root issue. Creating your own logging in a user database will solve this problem, though it's not the only way (such as using job scheduling software on another server).
Edit: I debated whether or not to put this in because while it is officially announced, all of the details behind the feature aren't public and are subject to change. However, in SQL Server 2019 (which isn't out yet, CTP 2.3 as of this writing) there are System AGs which do have master and model as part of the availability group. Since this functionality isn't currently available, the public documentation isn't available, and some items are subject to change, I hate to put this as an option but included it for completeness.