[PAC][runtimes] Fix signing/authentication oracles (if any) introduced by unwinding hardening

#143230 introduced usage of pointer authentication for hardening unwinding. As mentioned by @atrosinenko during review, usage of `__ptrauth`-qualified fields might cause signing or authentication oracles. We need to look through the introduced changes and fix the oracles found.

_Originally posted by @atrosinenko in https://github.com/llvm/llvm-project/pull/143230#pullrequestreview-2959407980_

> The fact I'm worried about is whether implicit signing and authentication on accesses to `__ptrauth`-qualified fields may introduce signing or authentication oracles usable by an attacker, since many values stored to these fields are initially non-signed. This is possibly mitigated by the fact that all these fields use address diversity with distinct integer discriminators and/or the original values are taken from read-only memory. On the other hand, discriminator computation, auth / sign intrinsic and load / store to memory are currently three separate operations when accessing a `__ptrauth`-qualified field, thus spilling of intermediate values to the stack is possible. Furthermore, even if the non-signed value originates from a read-only memory, this is not expressed in LLVM IR terms, thus the optimization pipeline may transform sensitive instruction sequences in an unsafe way.

Start by reviewing PR #143230 and the linked review discussion about __ptrauth-qualified fields in the unwinding hardening changes. Trace each introduced field access and assess whether implicit signing, authentication, discriminator computation, or intermediate spills can create an oracle. Done means identifying any vulnerable sequences and fixing them with appropriate validation.

Written by the indexing model from the issue text.