fix(finisher_api): resolve FindInBatches cursor primary key from dest schema

[wbrunovieira]

What this fixes

Model(A).FindInBatches(&[]B{}, ...) — where B embeds A but has a different field layout — panics with reflect: Field index out of range (v1.31.1) or, on current master, returns sql: converting argument $2 type: unsupported type gorm.Model, a struct and breaks pagination.

Reproduction: #7737 (playground: go-gorm/playground#848).

Root cause

The batch cursor reads the primary key of the last scanned row via result.Statement.Schema.PrioritizedPrimaryField.ValueOf(...). When a Model is set, Statement.Schema is the Model's schema, whose field Index path does not apply to the destination's element type — so the read resolves the wrong field (a whole embedded struct, or an out-of-range index).

The scan path already handles this by re-parsing the schema from dest when the element type differs from the Model type (scan.go:212-214). FindInBatches was the one place still reading the cursor value through the Model schema.

Fix

Resolve the cursor's primary field from the destination's own schema, matched by the Model's primary-key column name (LookUpField(DBName)), so the value always corresponds to the same column used in the ORDER BY / > comparison (which is built from the Model schema). The common case (dest type == Model type) keeps the Model's field unchanged. If dest has no field for that column there is no valid cursor, so it fails with ErrPrimaryKeyRequired instead of risking a wrong-index read.

Tests

TestFindInBatchesModelDestMismatch (in tests/) covers []B and []*B destinations and asserts every row is paged exactly once (no duplicate, no skip) across batches with batchSize < total. It fails without the fix (the exact #7737 error) and passes with it.

Closes #7737