Right now there isn’t enough information to conclude that the drive is “bricked”.

sg_format on a SAS drive with DIF enabled can absolutely make the disk temporarily unusable to the OS if the format parameters no longer match what the HBA/driver expects, but that is very different from a dead drive.

To make any determination, more data is required. At minimum (boot with a live Linux USB drive if you are unable to get to this information):

Please provide verbatim output from:

• dmesg -T (from boot and when the drive is detected)
• sblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC
• fdisk -l /dev/sdX
• sg_inq /dev/sdX
• sg_readcap -l /dev/sdX
• sg_modes -a /dev/sdX

Also specify:

• Exact drive model
• HBA model and firmware
• Kernel version / distro
• Whether the controller supports DIF/DIX (T10 PI)
• Whether other identical drives still work in the same slot/cable

Common possibilities (none can be confirmed without logs):

• Drive formatted with DIF enabled but HBA/OS not configured for it
• Logical/physical block size mismatch (e.g. 520/528 vs 512/4096)
• Format still in progress or left the drive in a non-ready state
• Mode pages changed that Linux does not like by default

Things that are usually recoverable on SAS drives:

• Re-formatting with correct sector size and DIF disabled
• Clearing protection information
• Power-cycling the drive after format completion
• Formatting from a controller that fully supports the drive’s feature set

Actual permanent bricking from sg_format alone is rare unless firmware flashing or vendor-specific commands were involved.

Until logs are posted, all anyone can honestly say is:

The drive is not currently usable, but there is no evidence yet that it is permanently damaged.

If you can share this information it might be possible to get the drive back online, though I make no promises.

(edit typos)