sigchain: recover from concurrent double-pops of the same signal - #2263

During git clone --depth 1 over ssh (or any transport that parks the
client with an in-flight packfile), two SIGTERMs delivered a fraction of
a millisecond apart can corrupt the sigchain unwind: both fetch threads
end up looping inside remove_junk_on_signal() at ~200% CPU, the process
survives both signals, and further SIGTERMs have no effect (only SIGKILL
recovers it).

Mechanism (git 2.56.0):

1. clone pushes two SIGTERM handlers: remove_junk_on_signal
   (builtin/clone.c:1134), then on the first tempfile activation (e.g.
   shallow.lock) remove_tempfiles_on_signal (tempfile.c:117):
   old[0]=SIG_DFL, old[1]=remove_junk_on_signal, n=2.
2. Two deliveries that land on two threads run the top handler
   concurrently; both sigchain_pop() calls read the same s->n and both
   install s->old[s->n - 1]: the chain unwinds two levels for two
   deliveries, ending at n=0 while the dispatcher still points at
   old[1].
3. The surviving dispatcher then chains to a handler that was already
   popped, whose own sigchain_pop() hits the n < 1 guard (a silent
   no-op), and whose raise() redelivers to the same stuck dispatcher
   forever.

This patch takes the "repair after the fact" route instead of
serializing the chain mutation: sigchain_pop() remembers how many
pushes were ever performed for the signal, and when it finds the chain
empty while the chain bottom is known, it reinstalls s->old[0] -- the
disposition that was in place before the chain was built. The stuck
handler's raise() then lands on that disposition (typically SIG_DFL)
and the process dies by it, exactly as a single delivery would have.

The repair is inert on every legitimate path to the n < 1 guard: if
the signal was never pushed nothing is installed, and if the chain was
fully unwound by regular pops, s->old[0] is already installed so
reinstalling it changes nothing. The push/pop fast path is untouched --
no locking, no signal-mask manipulation, no Windows-specific code.

Validation: a minimal reproducer (two threads parked in read(), the
same push/pop chain, first handler entry doing real close()+unlink()
work), compiled from identical sources with and without this change.
With a fault injector widening the gap between the "read n" and
"decrement n" steps of pop so both racing pops reliably read the same
value (300 interleaved pairs per arm), the unpatched arm froze 121/300
runs while the patched arm never froze: all 300 runs reinstated the
pre-chain disposition and died by it. 20/20 single-delivery control
runs never reached the repair code.

An alternative fix that serializes sigchain_push()/sigchain_pop() with
a per-signal spinlock exists as well; both eliminate the freeze. The
lock prevents the corruption, this patch heals it; they are independent
and either one suffices.