Encrypted APFS drive will not mount, RepairVolume reports disk OK I had to encrypt an external backup volume while traveling. Unfortunately, now the drive will not mount. It shows up in diskutil and RepairVolume shows the volume being OK. Despite the passphrase being stored in my Keychain, however, I am still prompted for it and providing the passphrase does not cause the disk to mount, nor does the 'mount' button in disk utitlities. Repair Volume shows the volume being OK but does not officially 'finish' (progress bar continues scrolling.)

 dxxx ~ $ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         500.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         371.0 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                128.4 GB   disk0s3
   4:           Windows Recovery                         505.4 MB   disk0s4

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +371.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            341.2 GB   disk1s1
   2:                APFS Volume Preboot                 47.6 MB    disk1s2
   3:                APFS Volume Recovery                510.3 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *5.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk4         4.9 TB     disk2s2
   3:       Microsoft Basic Data POISK                   127.8 GB   disk2s3

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *63.9 GB    disk3
   1:                 DOS_FAT_32 BUDrive                 63.9 GB    disk3s1

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +4.9 TB     disk4
                                 Physical Store disk2s2
   1:                APFS Volume Kosmos                  4.4 TB     disk4s1

Tue Oct 29 10:55 AM
dxxx ~ $ diskutil RepairVolume disk4
Started file system repair on disk4
Repairing storage system
Performing fsck_apfs -y -x /dev/disk2s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Kosmos was formatted by hfs_convert (945.275.7) and last modified by apfs_kext (945.275.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk2s2 appears to be OK
[\   \   \   \   \   \   \   \   \   \   \   \   \   \   \] 


I realize the very likely outcome is 'reformat disk' but there are a few files which travel logistics meant are not backed up, so if anyone has solved issues with encrypted apfs disks and has suggestions, I thought it worth asking first. Thanks so much!
Rather than using diskutil RepairVolume, which runs fsck_apfs -y, let's first see whether the APFS container has any issues with fsck_apfs -n. That is, please share the output of fsck_apfs -n /dev/disk2s2. This will run fsck on your APFS container, answering "no" to all questions (rather than -y, which answers "yes" to all).

Doing so will probably provide the same output as you have already provided, but should at least get you past the progress bar you're seeing, in case there are any further issues that fsck might report.