logictest: fix another flake in select_for_share

While stressing select_for_share for #129921, I noticed another rare
flake, where we sometimes have an unexpected shared lock appear in
`crdb_internal.cluster_locks` after a single SELECT FOR SHARE statement.

I think what's happening here is that a retry of the SELECT FOR SHARE
statement interacts with the shared lock from the previous execution,
causing an entry to appear in `crdb_internal.cluster_locks`. (We don't
always immediately clean up locks after a transaction finishes, which is
expected.)

I've simply removed the query. I don't think it's necessary to prove
correctness, as long as the following SELECT FOR UPDATE SKIP LOCKED
returns the expected row.

Informs: #129921

Release note: None

Author: michae2

pkg/sql/logictest/testdata/logic_test/select_for_share

@@ -216,11 +216,6 @@ SELECT * FROM t WHERE a = 1 FOR SHARE;
 
 user root
 
-query TTTTTTTBB colnames,retry,rowsort
-SELECT database_name, schema_name, table_name, lock_key_pretty, lock_strength, durability, isolation_level, granted, contended FROM crdb_internal.cluster_locks
-----
-database_name  schema_name  table_name  lock_key_pretty  lock_strength  durability  isolation_level  granted  contended
-
 # Locks:
 # 1: Shared
 # 2: None