if_bnxt: ktls: Reject new kTLS sessions once driver is detaching

[sumit.saxena_broadcom.com]

Summary

bnxt_tls_snd_tag_alloc() only gated on BNXT_STATE_OPEN, which is set
once by bnxt_open()/bnxt_attach_pre() but never cleared again, so it
could not reject new sessions once bnxt_detach() started tearing
things down. The snd_tag_alloc_ref-based wait in bnxt_detach(), which
waits for in-flight allocators to exit, was already in place, but
without this gate new sessions could keep being created for the
entire duration of that wait, extending it indefinitely instead of
just draining existing ones.

Reject new sessions once softc->detached is set, and reset it back to
false in bnxt_attach_pre() so it doesn't wrongly persist across a
detach/reattach cycle.

[sumit.saxena_broadcom.com]

AI scan fixes:

• The detached check ran once, before incrementing snd_tag_alloc_ref, with no relationship to the increment: an allocator thread that read detached == false and was then preempted could resume *after* bnxt_detach()'s drain loop had already observed ref == 0 (this allocator hadn't incremented it yet) and gone on to free ktls_info, so this thread's priv->ktls_info->snd_tag_alloc_ref access would touch freed memory. Re-check detached immediately after incrementing: bnxt_detach() sets detached (release-store) strictly before its drain loop, so if the increment is visible to that loop, detach correctly waits for the matching decrement instead. This narrows but does not fully close the race - doing that would need snd_tag_alloc_ref to live outside the struct bnxt_detach() frees, which is a larger restructuring than this fix attempts.
• Both detached accesses here, and the reset in bnxt_attach_pre(), now go through atomic_load_acq_int()/atomic_store_rel_int(), matching the field's type change to volatile int (see the detach-race commit).