fix(utils): restore FileWithLineNum caller depth and add regression test

[smf-h]

Summary

• restore FileWithLineNum() caller resolution behavior that regressed in v1.31.1
• extract stack scan into internal callerFrame(skip int) helper
• keep CallerFrame() API unchanged and use explicit skip handling
• add regression test for wrapped call chain (TestFileWithLineNumWrappedCallRegression)

Root cause

After #7610, stack scanning was extracted into CallerFrame(). The call path for FileWithLineNum() gained an extra wrapper frame, while fixed caller-depth handling caused wrapper-level frame resolution in v1.31.1.

Validation

• slog source behavior checked in local matrix probe (Info/Warn/Error/Trace): unchanged before vs after patch.

Fixes #7715

[qqxhb]

Thanks for the fix!

LGTM on the approach: keeping CallerFrame() semantics stable while making FileWithLineNum() explicitly select its own skip depth via an internal helper makes the call-stack sensitivity much clearer. The wrapped-call regression test is also a good addition and matches the pre-v1.31.1 behavior.

I ran go test ./... locally and it passed.

CI looks mostly green; the only failing job is tests/mysql (mysql:9, 1.24) which seems flaky across several recent PRs. Could you please re-run the failed job / workflow? If it goes green, this should be good to merge.

[smf-h]

Thanks for the rerun.

I checked the latest failed job:
https://github.com/go-gorm/gorm/actions/runs/22523502123/job/65501950447

This failure is different from the previous flaky test failure. It fails during dependency resolution, before test execution:

go: github.com/microsoft/go-mssqldb@v1.9.8 requires go >= 1.25.7 (running go 1.24.13)

In CI, tests/tests_all.sh runs go get -u -t ./... (tests/tests_all.sh:12), which upgrades dependencies at runtime.
So this looks like dependency drift in CI, not a regression from this PR’s utils changes.

Could a maintainer advise whether to pin deps / avoid -u in CI, or run this job with a compatible Go version?

[smf-h]

I don’t seem to have permission to rerun workflows on this PR from my side, so I’m unable to trigger the failed job directly.Could you rerun it,please?