cardinality: nil-safety check missing for FullIdxCols elements in getMostCorrCol4Index

## Summary

In `pkg/planner/cardinality/cross_estimation.go`, the function `getMostCorrCol4Index` directly dereferences `path.FullIdxCols[0].ID` (and potentially other indexed elements of `FullIdxCols`) without first checking whether the element is `nil`.

`IndexInfo2Cols` (now implemented via `indexInfo2ColsImpl` with `onlyPrefixCols=false`) is explicitly documented to return **sparse slices** — e.g., `[col1, nil, col2]` — where a `nil` entry means no corresponding `*Column` was found for that index column. Accessing `.ID` on a `nil` pointer will cause a **panic** at runtime when the first (or any) index column has no matching `*Column`.

## Steps to Reproduce

1. Have a table with an index where one or more index columns have no corresponding `*Column` resolvable via `IndexInfo2Cols`.
2. Execute a query that triggers `getMostCorrCol4Index` — the optimizer will panic with a nil pointer dereference.

## Suggested Fix

Add a nil guard before accessing `.ID` on `FullIdxCols` elements in `getMostCorrCol4Index`, similar to the patterns already used in:
- `pkg/planner/core/logical_plan_builder.go` (around line 4806–4807)
- `pkg/planner/core/exhaust_physical_plans.go` (around line 1273)

## References

- Identified during review of PR #66692: https://github.com/pingcap/tidb/pull/66692
- Review comment: https://github.com/pingcap/tidb/pull/66692#discussion_r2887349542
- Requested by: @henrybw