I think the component that prevents that packet from crossing from WAN to LAN is, precisely, the NAT. Or more specifically, that no dynamic NAT mapping has been established previosuly, from an outbound transmission from 192.168.1.2 towards the remote source of the packet.
Given how NAT works, if there hadn't been any outbound connection, there is no mapping of transport addresses in the NAT table, and thus an incoming packet is rejected. The firewall would be _behind_ the NAT, on the internal side, applying _additional_ rules to packets that did match some of the NAT mapping rules and were able to cross that boundary.
So to all effects, if the NAT discards an incoming packet, the firewall doesn't even get to process it.
Which is not to say that some vendors confuse this distinction, and call "firewall" to the NAT behavior.
That is only one specific, limited type of NAT, i.e. an "address dependent filtering" NAT.
The recommended (and common) form is EIM (Endpoint Independent Mapping), where one a private host+port (say 192.168.1.1:4567) has formed a connection to some public location (e.g. 1.1.1.1:53), and acquired a mapping on the WAN of (WAN-IP:pppp) then anywhere on the whole public Internet can form a connection to 192.168.1.1:4567 by sending packets to WAN-IP:pppp.
That is one of the ways in which NAT-Traversal ("hole punching") works. It has the nice property that P2P applications (e.g. online games) can form direct connections between devices behind NATs.
That same property generally applies for both TCP and UDP, and for all ports.
The thing which would prevent that in some NAT is the filtering behaviour, i.e. the session table which people are conflating with a firewall. If that filtering is also "Endpoint Independent" (which it often will be for consumer devices), then the above description applies.
If the filtering is "Address Dependent", or "Address and Port Dependent" then the more restrictive cases of other public internet devices not being able to use the mapping applies. However this is usually only seen with various forms of enterprise deployed NAT (since they often have firewalls also explicitly installed).
Given how NAT works, if there hadn't been any outbound connection, there is no mapping of transport addresses in the NAT table, and thus an incoming packet is rejected. The firewall would be _behind_ the NAT, on the internal side, applying _additional_ rules to packets that did match some of the NAT mapping rules and were able to cross that boundary.
So to all effects, if the NAT discards an incoming packet, the firewall doesn't even get to process it.
Which is not to say that some vendors confuse this distinction, and call "firewall" to the NAT behavior.