user5406: I'm looking for a detailed explanation of the exact weight, vsize and serialized length of a P2SH-P2WPKH (wrapped-segwit single-sig) input, in the same vein as How big is the input of a P2PKH transaction?.

user5406: TL;DR:
A P2SH-P2WPKH input should be conservatively estimated with 91.0 vbytes. Standard P2SH-P2WPKH inputs generally weigh 90.75 or 91.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 90.75 vbyte inputs. 91.0 vbytes is the conservative estimate allowing for high-r signatures.
Composition of a P2SH-P2WPKH input
Each input commits to spending a specific UTXO by providing its transaction outpoint:
PREVOUT: hash (32 bytes)
         index (4 bytes)

P2SH inputs contain a redeemscript in their scriptsig. For a P2SH-P2WPKH input this is a v0 witness program that redirects the script evaluation to the witness stack by committing to the hash of a pubkey:
SCRIPTSIG: length (1 byte)
  redeemscript length (1 byte)
  redeemscript (22 bytes)

Each transaction input has its own sequence number:
sequence (4 bytes)

A P2SH-P2WPKH input requires a witness stack in the transaction's witness block:
WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)

Conservative weight, vsize, and size estimate
A P2SH-P2WPKH transaction input adds to a transactions…
weight:
4 × (32 + 4 + 1 + 1 + 22 + 4) + 1 + 1 + 72 + 1 + 33 = 4×64 + 108 = 364 WU

vsize:
32 + 4 + 1 + 1 + 22 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 91 vbytes

serialized byte length:
32 + 4 + 1 + 1 + 22 + 4 + 1 + 1 + 72 + 1 + 33 = 172 bytes

If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes and the above maxima to 363 WU, 90.75 vbytes, and 171 bytes respectively.
Note that using at least one segwit input adds 2 witness bytes to the transaction header, the witness marker and witness flag. Also, when there is at least one segwit input, the witness block must have a witness count item for every input, which must be provided as a 0x00 byte for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:
version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness item counts (1 WU × input count)
  witness stacks (variable weight)
locktime (4 bytes)

Mentioned for completeness, a P2SH-P2WPKH input that has a non-standard signature with both high-s and high-r weighs 365 WU, 91.25 vbytes, and 173 bytes accordingly.

¹ also see What is the maximum size of a DER encoded ECDSA signature?.

5406: <p>I'm looking for a detailed explanation of the exact weight, vsize and serialized length of a P2SH-P2WPKH (wrapped-segwit single-sig) input, in the same vein as <a href="https://bitcoin.stackexchange.com/q/48279/5406">How big is the input of a P2PKH transaction?</a>.</p>
 5406: <p><strong>TL;DR:</strong><br />
A P2SH-P2WPKH input should be conservatively estimated with <strong>91.0 vbytes</strong>. Standard P2SH-P2WPKH inputs generally weigh 90.75 or 91.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 90.75 vbyte inputs. 91.0 vbytes is the conservative estimate allowing for high-r signatures.</p>
<h2>Composition of a P2SH-P2WPKH input</h2>
<p>Each input commits to spending a specific UTXO by providing its <em>transaction outpoint</em>:</p>
<pre><code>PREVOUT: hash (32 bytes)
         index (4 bytes)
</code></pre>
<p>P2SH inputs contain a redeemscript in their <em>scriptsig</em>. For a P2SH-P2WPKH input this is a v0 witness program that redirects the script evaluation to the witness stack by committing to the hash of a pubkey:</p>
<pre><code>SCRIPTSIG: length (1 byte)
  redeemscript length (1 byte)
  redeemscript (22 bytes)
</code></pre>
<p>Each transaction input has its own <em>sequence</em> number:</p>
<pre><code>sequence (4 bytes)
</code></pre>
<p>A P2SH-P2WPKH input requires a <em>witness stack</em> in the transaction's witness block:</p>
<pre><code>WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)
</code></pre>
<h2>Conservative weight, vsize, and size estimate</h2>
<p>A P2SH-P2WPKH transaction input adds to a transactions…</p>
<p><strong>weight:</strong></p>
<pre><code>4 × (32 + 4 + 1 + 1 + 22 + 4) + 1 + 1 + 72 + 1 + 33 = 4×64 + 108 = 364 WU
</code></pre>
<p><strong>vsize:</strong></p>
<pre><code>32 + 4 + 1 + 1 + 22 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 91 vbytes
</code></pre>
<p><strong>serialized byte length:</strong></p>
<pre><code>32 + 4 + 1 + 1 + 22 + 4 + 1 + 1 + 72 + 1 + 33 = 172 bytes
</code></pre>
<p>If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes and the above maxima to 363 WU, 90.75 vbytes, and 171 bytes respectively.</p>
<p>Note that using at least one segwit input adds <strong>2 witness bytes</strong> to the transaction header, the <em>witness marker</em> and <em>witness flag</em>. Also, when there is at least one segwit input, the witness block must have a witness count item for <strong>every input</strong>, which must be provided as a <code>0x00</code> byte for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:</p>
<pre><code>version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness item counts (1 WU × input count)
  witness stacks (variable weight)
locktime (4 bytes)
</code></pre>
<p>Mentioned for completeness, a P2SH-P2WPKH input that has a non-standard signature with both high-s and high-r weighs 365 WU, 91.25 vbytes, and 173 bytes accordingly.</p>
<hr />
<p><sup>¹ also see <a href="https://bitcoin.stackexchange.com/a/77192/5406">What is the maximum size of a DER encoded ECDSA signature?</a>.</sup></p>
