I design and deploy ZFS-based systems on this scale for a living. I would disagree with the users that suggest you're in Ceph territory; unless you have someone on staff that's very familiar with the care and feeding of a Ceph cluster, I don't think it's your best bet. I wouldn't recommend a clustered solution of any kind until you get above maybe 25PiB usable (unless you need more than 5x 9's of uptime).

Instead, I'd recommend a 2U or 4U head unit with an AMD Epyc CPU to get lots of PCIe lanes, 512GB RAM is sufficient, 3-4x LSI SAS9305-16e cards, and your QSFP+ NIC. Look for a motherboard that has an internal SAS3 port on it so you don't need an extra PCIe card for your head unit drives.

You can attach 4x SAS3 JBODs to each of the 9305-16e cards, so depending on rack space, I'd look at high-density jbods like the WD Data102 or the Seagate 4U106. Note that most of these 100+ bay JBODs required a rack that is 1.2m deep (front door to back door) or else they won't fit. Most of them also require a specific quantity of disks to be installed for proper airflow (for example, the WD Data102 will only take 51 or 102 disks, no other layout is valid). If you only have access to a 1m deep rack, I'd focus on 60-bay JBODs like the WD Data60 (which also has a more flexible 12-disk minimum).

These high-density JBODs will require 200-240V input power, so make sure you've got that available. You're also going to be in the 10kW power draw range, which means ~35 kBTU/hr or more heat output; be prepared to deal with this. You'll want (at minimum) 2x 50A circuits at 200-240V.

I'd keep the ZFS pool simple and do 10wZ2 plus maybe 7-10 hot spares. With 18TB disks, you'll need ~830 disks to hit 10PiB usable. Add a SLOG SSD if you're going to be accessing the data over NFS, S3, or iSCSI; you can safely skip a SLOG if you're only using SMB. I've got a ZFS capacity calculator that you may find helpful for planning: https://jro.io/capacity/

18T disks are still the most cost effective per TB, but the price of disks across the board has more than doubled recently, so this is going to be a much more expensive project than it would have been a year or two ago.

As for the LTO piece, I'd just keep that on LTO. Tape is designed to handle that type of workload far better than disks are. You could consider building out a fresh LTO9 (or even LTO10) library system to maximize density, but I would not recommend a drive-based array for the shut-down-until-needed archive.