Need understanding on Wireshark Capture from LSA update of a link.PCAP attached

So, after working with JTAC yesterday, "I", as in I really didn't need JTAC since I figured out the issue on my own.. realized that my firewall filter was a bit redundant and was lacking a "permit any" statement.

OSPF adjacency was breaking because the firewall filter was taking the "else" traffic (term DEFAULT) and sending it to routing-instance PATH-2, which didn't help either way since it was sending traffic right back to SW-2, something a "then accept" statement would have done easily

So, to repair the issue..

New SW-2 & RTR-2 corrected configlets:

delete routing-instances PATH-2
delete firewall family inet filter FBF-TEST term DEFAULT
set firewall family inet filter FBF-TEST term PERMIT-ANY then accept

New config snips for SW-2:

routing-options {
    nonstop-routing;
    interface-routes {
        rib-group inet STAGING-RIB;
    }
    static {
        route 10.100.190.0/24 next-hop 10.100.100.2;
        route 10.100.191.0/24 next-hop 10.100.100.2;
    }
    rib-groups {
        STAGING-RIB {
            import-rib [ inet.0 PATH-1.inet.0 ];
        }
    }
    router-id 10.100.254.1;
}
firewall {
    family inet {
        filter FBF-TEST {
            term TERM-1 {
                from {
                    source-address {
                        10.100.190.0/24;
                        10.100.191.0/24;
                    }
                }
                then {
                    routing-instance PATH-1;
                }
            }
            term PERMIT-ANY {
                then accept;
            }
        }
    }
}
routing-instances {
    PATH-1 {
        instance-type forwarding;
        routing-options {
            static {
                route 10.100.30.0/24 {
                    next-hop 10.100.254.2;
                    qualified-next-hop 10.10.10.1 {
                        preference 100;
                    }
                }
            }
        }
    }
}

New config snips for RTR-2:

routing-options {
    interface-routes {
        rib-group inet STAGING-RIB;
    }
    rib-groups {
        STAGING-RIB {
            import-rib [ inet.0 PATH-1.inet.0 ];
        }
    }
    router-id 200.200.200.2;
    autonomous-system 1;
}
firewall {
    family inet {
        filter FBF-TEST {
            term TERM-1 {
                from {
                    source-address {
                        10.100.190.0/24;
                        10.100.191.0/24;
                    }
                }
                then {
                    routing-instance PATH-1;
                }
            }
            term PERMIT-ANY {
                then accept;
            }
        }
    }
}
routing-instances {
    PATH-1 {
        instance-type forwarding;
        routing-options {
            static {
                route 10.100.30.0/24 {
                    next-hop 200.200.200.1;
                    qualified-next-hop 10.100.254.1 {
                        preference 100;
                    }
                }
            }
        }
    }
}

After more thoroughly combing through the RFC, I'm certain that the expected behavior I mentioned in my post is accurate.

Intra-area routing within each area (area 1, area 0(a), and area 0(b)) will work as expected.

Area 0 summaries will still flood to area 1 from each area 0 partition, giving area 1 all necessary routing information for both area 0 partitions.

Area 1 summaries will still flood to both area 0 partitions from area 1, allowing both area 0 partitions to know about area 1 routes.

Area 1 will not send area 0 summaries back into area 0, so split area 0 partitions will no longer know about each other and will not try to transit area 1 to get to each other (unless a virtual link through area 1 is created).

This is my desired behavior for a failure scenario based on my circumstances. If all of the redundant links between my data centers go down, or I need to perform certain types of maintenance, I don't want data center to data center traffic (mostly backups / off-site replication) saturating my branch site WAN links. I could apply policing on the WAN links for transit traffic between data centers, but the little bit of bandwidth I could give that traffic would be useless anyway - and that would require my team to maintain more config.

If anyone has any questions about this, feel free to comment and I will try to find the answers.