LTO-9 READ_ATTRIBUTE and LOG_SENSE timeout values are too small

Describe the bug

Hello! We use LTFS 2.4.7.1 from GitHub (with Phobos) and IBM LTO-9 SAS drives. According to IBM, when a Read Attribute command is issued, the drive might generate an EOD and in our case, the drive was not able to set the write head position to the track (apparently a thing if the tape was calibrated using v21). The drive enters a recovery process of up to 10 x 12 seconds. It looks like in LTFS, the timeout for READ_ATTRIBUTE is hardcoded to 60s which is then too low in this case. IBM told us that "If the command was not aborted, the drive may be able to write the EOD to the tape."
This is why these timeout values should probably be set to either 120s or 132s (IBM did not exactly specify this yet, we're waiting to hear from them).

BTW, I tried to increase the value define here to 120 and recompiled LTFS but unfortunately I am still seeing occasional Read Attribute timeout occurrences still at 60s. I wonder why 60s is still used and what I missed... Any ideas?

[456431.184458] st 1:0:1:0: attempting task abort!scmd(0x000000008b10e4e8), outstanding for 62233 ms & timeout 60000 ms
[456431.184486] st 1:0:1:0: tag#4695 CDB: Read attributes 8c 00 00 00 00 00 00 00 00 09 00 00 00 0d 00 00

To Reproduce

Write files using LTFS 2.4 for example with Phobos (medium synchronization every 500 files / 16 GiB).

Expected behavior
Longer READ_ATTRIBUTE timeout to allow the drive doing its special recovery when an EOD is needed.

Additional context
OS is Rocky Linux 9.5

Start at src/tape_drivers/ibm_tape.c around the timeout definition linked in the report, then trace all READ_ATTRIBUTE and LOG_SENSE timeout paths to identify why a 60-second timeout remains. Reproduce the reported LTO-9 behavior using the provided command output and medium-synchronization scenario. Done means the agreed longer timeout is applied consistently and the 60-second abort no longer occurs during the drive's recovery.