A bare hex/string literal as a tuple-declaration component panics instead of taking the component's bytesN type

Source

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.35;

/* ===ARENA-MANIFEST===
{
  "deploy": {
    "contract": "T",
    "args": []
  },
  "entry": {
    "function": "run",
    "args": []
  },
  "feature": "bare-literal-in-tuple-declaration",
  "note": "solc 0.8.35 + EVM: a bare hex literal as a component of a TUPLE DECLARATION takes its bytesN type from the declared component, so `(bytes4 v, uint256 w) = (hex\"11223344\", uint256(1));` binds v = 0x11223344 and the call returns 0x11223344 + 1 = 287454021. solidity-lean raises Panic(0). The same literal in a single declaration (`bytes4 v = hex\"11223344\";`) works, so the tuple component is a missing target-typing arm, not a general literal gap. Reproduces for tuple ASSIGNMENT too, and for a bare string literal (`\"abcd\"`) in the same positions. Distinct from the custom-error argument case, which fails with WRONG revert data rather than a panic."
}
===END-ARENA-MANIFEST=== */

contract T {
    function run() public pure returns (uint256) {
        (bytes4 v, uint256 w) = (hex"11223344", uint256(1));
        return uint256(uint32(v)) + w;
    }
}