drm/i915: Avoid post-put frontbuffer object access [FreeBSD]

[JustAnotherHumanBeing]

Summary

• cache the i915 device pointer before clearing the object's frontbuffer
• avoid deriving the warning target and fb-tracking lock from a GEM object after its final reference may have been dropped

Root cause

i915_gem_object_set_frontbuffer(obj, NULL) can release the final GEM object reference. On FreeBSD, object reclamation may run before the following statements in frontbuffer_release(). The old code then dereferenced obj again to find i915->display.fb_tracking.lock.

A captured panic showed drm_gem_object_free() followed by an unlock through a poisoned 0xdeadc0de... pointer in intel_frontbuffer_put(), reached from DRM_IOCTL_MODE_CLOSEFB.

Caching i915 while obj is still referenced preserves the existing lock and reference ordering while removing the post-put dereference.

PR #469's Linux 6.13 conversion also avoids this sequence as a side effect. This PR is a minimal fix for the current 6.12-based master and does not depend on the full version update.

Testing

• built i915kms.ko from official master with make -C i915 -j12 DEBUG_FLAGS=-g SYSDIR=/usr/src/sys and -Werror
• verified the generated code retains the cached device pointer across drm_gem_object_free()
• booted the corrected module and ran Plasma/KWin through the startup path that previously panicked, with no recurrence