Do you need the server to also access the public network or only reply to requests from the public network?
On the first case you use static nat (bidirectional NAT), on the second you use destination nat.
Regarding your ping tests you're trying to ping an IP that, due to the proxy-arp config, is configured to respond only from the ge-0/0/0 interface. Maybe you could try to ping it like this: ping 10.129.166.135 source 10.129.166.132, but I'd recommend to reconfigure the "natted" IP to the server since it will be easier to troubleshoot.
I also noticed that the vlan.60 interface is not configured in the trust zone, so besides other issues, all the traffic to/from the vlan.60 subnet will be blocked and the nat config won't be applied.
As a side note, I have no idea what type of public network you're connected to but the host-inbound-traffic configuration on the wan security zone should be reduced to the absolute minimum or, if possible, removed as this only controls the traffic to the firewall itself (for example, to allow a ssh connection or to ping the firewall from the public network).
proposed solution with destination nat + port-forward
This example/solution will use the address of the wan interface and map a port (5000) to the port 22 (ssh) of the internal address:
set security nat destination pool DestinationNatVideo address 192.168.3.100/32
set security nat destination pool DestinationNatVideo address port 22
set security nat destination rule-set RuleSetVideo from zone wan
set security nat destination rule-set RuleSetVideo rule r1 match destination-address 10.129.166.132/32
set security nat destination rule-set RuleSetVideo rule r1 match destination-port 5000
set security nat destination rule-set RuleSetVideo rule r1 then destination-nat pool DestinationNatVideo
You can also remove this set security nat destination pool DestinationNatVideo address port 22 and it should map the port 5000 to all services of the internal IP (it's better to map one port per service instead of leaving everything open/connectable).
The version that's installed in your device is a bit old and maybe it doesn't support nat very well (or just some parts of it) so YMMV.
Having spent many weeks working with JTAC to find a solution... the answer was simply to reboot the node which is missing from the SNMP output.
I have set up a few SRX (345) clusters since having this issue and each time they have exhibited the fault. JTAC could not replicate so it's unlikely they will fix it.
Best Answer
In a Juniper SRX Chassis Cluster, the master Routing Engine (RE) runs on only one node. This creates an active/passive control plane. All control plane processes (rpd, kmd, etc.) run only on the master RE.
From Branch SRX Series and J Series Chassis Clustering: