Understanding Heap Read/Heap Hit
You are treating it as if block reads are a subset of block hits.  That isn't correct, the two are mutually exclusive.  To get a real hit ratio, you would have to compute as  sum(hits)/sum(hits+reads). But just looking at hit ratios is pretty useless anyway, in general but especially in PostgreSQL which doesn't use DirectIO but rather sits on top of the OS's file cache.  Hit ratios are part of mythology-based administration.

For all we know, this table has only had one or two seq scan done on it (for example, the ones which were done in order to create the index in the first place) and that event is now dominating your statistics.  You could reset the statistics (or better yet just stop looking at them) to get rid of one-time events.

The columns seq_scan, seq_tup_read, idx_scan, idx_tup_fetch are occasionally (but rarely) useful in figuring out the source of a problem when a problem is known to exist. They are entirely useless when there is no problem to diagnose in the first place.

You should instead spend your time doing useful things, like setting up a slow query log ("log_min_duration_statement" or better yet auto_explain, and pg_stat_statements), setting up test/dev/QA environments, or running disaster recovery drills so you know know that your backups are working and that you know how to use them.

My favorite settings of auto_explain for new projects are:

shared_preload_libraries = 'auto_explain'
track_io_timing=on
auto_explain.log_min_duration = '50ms'
auto_explain.log_analyze=on
auto_explain.log_timing=off
auto_explain.log_buffers=on


And then increase log_min_duration if you find it is catching too many queries.

Having log_analyze=on while also having log_timing=on imposes a pretty high overhead on all your queries; so setting log_timing=off is a compromise to get as much detail as possible but with minimal overhead.