MVPN Source PE might incorrectly send mcast traffic on SPTree while actual receiver is still on RPTree resulting in traffic blackhole

In current MVPN flow, when a provider tunnel is being deleted, it is assumed the cmcast routes associated to the ptnl would've have been updated before. 
This is fine for inclusive tunnels, however for selective tunnels especially wild card scenarios the cmcast routes may not be updated. 
So in cases where the ptnl is deleted like configuration based removal or underlying tunnel going down, 
There is chance that the forwarding routes are still not deleted. 
The cmcasts are deleted later in the flow but when they are deleted the corresponding forwarding routes are still not deleted since there is no corresponding ptnl for the cmcast. 
This will create issues if forwarding is supposed to happen via different forwarding entry like a *,G entry but since the more specific S,G stale entry exists,
 Traffic will hit the later and lead to unexpected behavior like traffic black-holing if S,G is Pruned entry.

labroot@MX960-RE0> show multicast route group 224.0.129.61 instance xxxxx.aaa extensive 
Instance: xxxxx.aaa Family: INET

Group: 224.0.128.61/32
    Source: *
    Upstream interface: ae4.2206
    Downstream interface list:    <------ Mcast receiver on ae8.5
        ae8.5
    Number of outgoing interfaces: 1
    Session description: Unknown
    Statistics: 0 kBps, 0 pps, 0 packets
    Next-hop ID: 1048966
    Upstream protocol: MVPN
    Route state: Active
    Forwarding state: Forwarding
    Cache lifetime/timeout: forever
    Wrong incoming interface notifications: 0
    Uptime: 1d 22:40:31

Group: 224.0.128.61
    Source: 122.122.122.122/32
    Upstream interface: ae4.2206
    Number of outgoing interfaces: 0
    Session description: Unknown
    Statistics: 1 kBps, 7 pps, 2193509 packets  <------ No receiver in downstream list but traffic continues to flow on SPT, resulting in blackhole
    Next-hop ID: 1049945
    Upstream protocol: MVPN
    Route state: Active
    Forwarding state: Pruned
    Cache lifetime/timeout: forever
    Wrong incoming interface notifications: 0
    Uptime: 4d 06:35:27

Workaround is to move provider tunnel from selective to inclusive.

Permanent fix is  software upgrade to following releases

evo:24.4R2-EVO evo:25.2R2-EVO evo:25.3R1-EVO evo:25.4R1-EVO junos:24.4R2 junos:25.2R2 junos:25.3R1