Ah, I see what's happening.

There's a SELECT earlier in the (implicitly started) transaction that's taking a table-level shared lock. You're going to have to identify what that select...

https://www.red-gate.com/simple-talk/sql/t-sql-programming/how-to-confuse-the-sql-server-query-optimizer/

Specifically the second section

Restore the last full backup before the data was deleted WITH NORECOVERY, then restore the last differential backup WITH NORECOVERY, then restore all log backups after that point WITH NORECOVERY,...

What are the settings for Allow_row_locks and Allow_Page_locks for that table?
An update of 3 rows, filtered by the clustered index should not be taking table locks.

https://www.sqlinthewild.co.za/index.php/2009/01/19/index-columns-selectivity-and-equality-predicates/

Unless you take your backup WITH CHECKSUM, the verify just reads the header. It's pretty worthless.

Don't fiddle with your lock escalation or page/row lock settings unless you know EXACTLY what you're doing and why. You can cause some serious problems messing with those.

Locking happens on a row, page or table basis, always within a single database. Blocking does not happen at the server or database level (unless you're doing server reconfigurations or...

Not unless you want to break the log chain, compromise the DB's recoverability in the case of a disaster.

Restarting the log backups would have cleared the log, allowing...

The only thing you can configure there is the DB's recovery model, which affects how long log records are retained, and whether some operations will be minimally or fully logged.