it shouldn’t be merged if it’s not deployable.

100 % agree. The purpose of post-merge testing is to have an extra layer of security to prevent bugs from leaking out into prod, not that you should ever consciously merge something that is not deployable. In my experience, testing on a feature before merge tends to focus on what you expect could be broken/bugged. The post-merge/pre-deploy testing exists to catch cross-feature bugs and in general find the stuff you never expected to break in the first place. Basically: Test your feature thoroughly before merging, then test the whole app without focusing on any particular feature before deploying.

after merging it should start the deployment process automatically (...) it’s not that common for things to have to have manual deploys

There's two sides to this: We have auto-deploy on merge to a staging environment, and a manual deploy to prod. That lets us keep a high rate of development, while we continuously test / use the staging environment internally. The manual prod deploy doesn't cost us any extra time, since it essentially consists of clicking the "deploy to prod" button. The advantage is that we typically get a couple days of delay from something hitting staging before it goes to prod, which has let us catch a couple embarrassing bugs before they hit customers. When that happens, we can improve our testing regime without the bug having ever hit prod in the first place.

So basically, before I click the "deploy to prod" button, I spend maybe 15 minutes clicking around in the staging environment to double-check that all is good, then I double-check that we don't have any known blocking bugs (we just use a dedicated issue-tag for "I found a deploy-blocker on staging, don't deploy to prod before it's fixed.")