Xtensa: fix SLLI shift amount of 32 not being printed

[Samin061]

Summary

For Xtensa slli with a shift amount of 32, the shift was missing from the
printed text, and builds with assertions enabled aborted.

Reproducer

Arch CS_ARCH_XTENSA, mode esp32 (also esp32s2 and esp8266), bytes 00 e8 01:

• Before: slli a14, a8, with the shift missing, although the detail operand
  correctly holds imm 0x20. With assertions enabled, it aborts in
  printShimm0_31_AsmOperand (arch/Xtensa/XtensaInstPrinter.c:271).
• After: slli a14, a8, 0x20

Found by running random bytes through cs_disasm on every architecture under
ASan and UBSan.

Cause

SLLI stores 32 - shift in a 5-bit field. The decoder
(decodeShimm1_31Operand) correctly turns field 0 into a shift of 32, but the
printer only accepted 0–31, so its range check failed and the operand text was
never printed.

32 is the correct value: GNU binutils' Xtensa tables (bfd/xtensa-modules.c,
operand msalp32) also decode field 0 as 32. The 0–31 range comes from
Espressif's LLVM fork, which the Xtensa module is generated from. It declares
SLLI's operand as shimm0_31 but decodes it as 1–32. Upstream LLVM main uses
shimm1_31 for SLLI and has the same mismatch.

Fix

The printer now accepts 0–32, with a one-line comment
(XtensaInstPrinter.c:269). This operand range is used only by SLLI. This is
a hand edit to a translated file, which auto-sync allows and preserves on
regeneration.

I kept 0 in the range (rather than 1–32, since the decoder never produces 0)
so the check still holds if the decoder is later regenerated to map field 0
to 0. Happy to change it to 1–32 if you prefer.

Testing

• New case at the end of tests/details/xtensa.yaml, checking both the text
  and the operand detail. It aborts without the fix and passes with it.
• Full local suite (27 ctest tests) passes in a Debug ASan+UBSan build; the
  new case also passes in a Release build.
• Random-input fuzzing of the three Xtensa modes is clean after the fix.
• clang-format makes no changes; git diff --check is clean.

Not included

The same fuzzing found a RISC-V issue: cv.bitrev (db 16 18 db on riscv32).
The generated table reads its 2-bit immediate as 5 bits, and upstream LLVM has
the same bug. A proper fix means changing LLVM's instruction definitions and
regenerating the tables, so I'll leave that for a separate PR or issue.

AI disclosure

none

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (next@d01f16f). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             next    #3130   +/-   ##
=======================================
  Coverage        ?   61.29%           
=======================================
  Files           ?      243           
  Lines           ?    56814           
  Branches        ?    10075           
=======================================
  Hits            ?    34822           
  Misses          ?    16794           
  Partials        ?     5198           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.