What about if this node is the local node? Do we also need to plumb the local node's pod CIDR into the ipcache?

Not for tunneling (we don't insert local node allocation CIDRs into the tunnel map).
But it is something we can consider if any other feature can benefit from these new entries.

Drive-by comment, there's no need for an extra ipcache lookup here, because all callers already performed it (that's how tunnel_endpoint gets normally populated). E.g,, https://github.com/pippolo84/cilium/blob/pr%2Fpippolo84%2Fmerge-tunnel-map-into-ipcache-exp/bpf/bpf_lxc.c#L920-L928

I haven't explicitly checked the other functions below, but AFAIR the same applies there as well.

I had the same thought when first looking at it. One subtlety is that the initial ipcache lookup uses the precise IP, while here we use the (fixed-size) PodCIDR (as that's what the caller passed in the tunnel_key).

So right now this is a 1-to-1 replacement. Without considering that the IPcache is LPM and we would have already matched the PodCIDR entry on the first lookup.

Ah right, this is using the masked IP as key. My comment was based on the fact that being the ipcache an LPM map, the node entry would already been retrieved during the previous lookup. And we'll also need to get rid of the fixed mask to benefit from the additional flexibility provided by the ipcache.

Drive-by comment, there's no need for an extra ipcache lookup here, because all callers already performed it (that's how tunnel_endpoint gets normally populated).

Tried that approach in #37146 and it seems to work correctly.