The firewall has two reload flavors:
- A restart mode which will destroy the entire ruleset, rebuild it from scratch and process all includes and user scripts
- A reload mode which will clear and rebuild internal chains while leaving the rest of the rule set mostly intact. However in order to free up internal chains and being able to delete them, all rules pointing to such internal chains are deleted as well. For firewall-internal rules this is no issue, as they'll be recreated immediately. But rules stemming from external sources will be lost after such a reload.
In your case, the zone_lan_input chain is an internal one, so the iptables -I zone_lan_input -t filter -j misc-lan-rules rule referencing it will get deleted during firewall reloads which may happen frequently due to various events.
Setting option reload 1 will cause your include script to be executed with every reload as well and not just on restarts which will take care of readding your iptables -I zone_lan_input ... rule.
If you do that though, you must rework your script to avoid creating duplicate rules with each firewall reload as only those rules "touching" internal chains (e.g. -I zone_lan_input ... or ... -j zone_lan_input) are deleted while others (e.g. -A misc-lan-rules ... ones) remain intact.
One can do that by using wrappers such as ipt() { iptables -D "$@" 2>/dev/null; iptables -A "$@"; } which will first emit a rule deletion request before each corresponding rule add.
On the other hand it is far easier to simply use the user hook chains, in your case input_lan_rule which do not suffer from the "deletion" problem.
You can see an overview over the chain structure here: https://oldwiki.archive.openwrt.org/doc/uci/firewall#packet_flow
Any chain not marked "internal" is safe to use as either container or jump target.