To add to Zac67's answer:
why router B pre-fragment packets to send before router C
Fragmentation is expensive in terms of system ressources on routers, and should be avoided.
Routers and Firewalls with modern multicore CPUs and Security ASICs can shoulder a lot of fragmentation work and masquerade the underlying issue. Low- and mid-range routers and L3-switches will punt such workload from their forwarding ASIC (if at all present) to the CPU - and this can kill performance drastically. Single digit Mbit/s throughput, even on Gigabit links can be the result.
If ComputerA supports PathMTUdiscovery and sets the "do not fragment" bit in the header of its IP packets, RouterB may make use of PathMTUdiscovery to let Computer A know that it should send smaller sized packets when talking to ServerA. (see Zac67's answer).
It does this by sendig an ICMP Type 3 Code 4 message ("fragmentation needed but don't fragment set") back to Computer A, which also includes a suggested max packet size and the packet header of the packet that caused the error.
If ComputerA ingests this message and processes it successfully, it will react by sending no more IP packets larger than suggested max packet size towards ServerA. This setting is individual per-destination; when talking to other destination hosts (for example on the local LAN), ComputerA will still use its standard packet size.
Some of this can also be achieved if Routers B and C are configured to perform TCP MSS Clamping. With TCP MSS Clamping, the routers manipulate the SYN and SYN-ACK packets exchanged between ComputerA and ServerA at the start of a TCP session, and they trick both ServerA and ComputerA into believing that the remote peer can only accept a given (lower) number of payload bytes per TCP segment (TCP Maximum Segment Size: usually IP MTU - 40bytes, so here: 1360 bytes).
This will cause both ServerA and ComputerA to send TCP segments with no more than 1360 bytes of payload when talking to each other for the given TCP session, while still using normal TCP segment size when talking to other computers.
TCP MSS clampig is a bit of a kludge: It only works for/with TCP. UDP and other applications must rely on PMTUD, probe the PathMTU themselves somehow, or must be configured to send a given max packet size.