APIM and APP GW failover current sessions or they suffer a session termination?

Hi - The info you require for reliability can be found here

https://video2.skills-academy.com/en-us/azure/api-management/high-availability for APIM with more info here https://video2.skills-academy.com/en-us/azure/well-architected/service-guides/api-management/reliability

And

Here https://video2.skills-academy.com/en-us/azure/application-gateway/application-gateway-autoscaling-zone-redundant for App GW with more info here https://video2.skills-academy.com/en-us/azure/well-architected/service-guides/azure-application-gateway

In short where you have a 1:1 (where APIM is the only backend pool member) then consider that APIM tiers are deployed with 2 or more actual compute instances behind an LB - this is where it's useful for APIM, APP GW and any other upstream or downstream dependencies on the same critical path - to be using Zones.
Zones are each data centres and each represent a giant fault and update domain.
Az PaaS Services like APIM and AppGW which are deployed with zones enabled distribute the compute workers across zones, so if a zone faults then the service is temp degraded (in theory then it could be the loss of 1/2 or 1/3 compute nodes) but they're still "Up".

If you dont deploy across zones - then PaaS like APIM and App GW still have more than one VM worker -but you wont get the same level of reliability because that compute may, for example, be in a single zone

if APIM was go go offline either because it's compute was offline, or for another reason (for example saturated with a sudden increase in load) then the response back through App GW would be a 5xx error
if AppGW goes offline similarly you may expect a bad gateway/5xx error at the client

*

More advance strategies include active active, or active-passive deployments cross region and using a global load balancer (Az Front Door, or Traffic Manager) between client and AppGW/APIM to provide regional redundancy . Global load balancers use probing for automatic failover, or you can failover manually based on alerts (perhaps other steps are required and not all can be automated)