sql/inspect: might silently miss dangling secondary index entries on tables with a collated-string primary key

**Summary**

The INSPECT index consistency check can fail to detect a dangling secondary index entry (a secondary index KV with no matching primary-index row) when the table's primary key includes a `STRING COLLATE …` (or `CITEXT`, or an array/tuple of collated strings) column. The check completes successfully and reports no inconsistency, so real index corruption goes unreported.

**Impact**

- Silent false negative in a correctness-verification tool. INSPECT reports "no inconsistencies" on a table that has them.
- Scoped to forward-index consistency checks on tables whose PK contains a collated-string column, for key spans that hold no primary-index rows.

**Root cause**

When a span has no primary-index rows, the dangling-entry check derives its scan bounds directly from the span's boundary keys (the `needBoundsWhenEmpty` path → `decodeSpanKey`). That decode is key-only and has no access to the composite value where a collated string's original contents are stored. A collated string is key-encoded as a one-way collation sort key, so decoding yields a garbage datum, and the resulting predicate bounds no longer cover the dangling entry. (This mirrors `rowenc.DecodeIndexKey`'s documented "does not handle composite encoding" limitation; the has-rows path avoids the issue by decoding actual rows via the composite-aware `DecodeIndexKeyToDatums`.)

Non-collated columns are unaffected: their key encoding is invertible (float/decimal decode to a Compare-equal representative that re-encodes identically), so only collated strings produce a wrong boundary.

Jira issue: CRDB-68414