The behavior of SELECT FOR UPDATE is inconsistent between TiDB and MySQL

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

```sql
/* init */ drop table if exists tt;
/* init */ create table tt (a int primary key, b int, c varchar(255));
/* init */ insert into tt values (1, 11, 'snapshot');
/* init */ insert into tt values (2, 12, 'snapshot');

/* t1 */ begin;
/* t1 */ update tt set c='latest' where b=11;
/* t2 */ begin;
/* t2 */ select * from (select * from tt where b=11) as t for update;
/* t2 */ select * from (select * from tt where a=1) as t for update;
/* t1 */ commit;
/* t2 */ commit;
```

### 2. What did you expect to see? (Required)

Either the first select of t2 is blocked, or neither of the two queries is blocked.

BTW, according to the mysql [doc](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html), both selects do not lock the row.


### 3. What did you see instead (Required)

Although the first select uses select-lock. It should have attempted to acquire a lock and been blocked, however, since it is in a subquery and the planner did not provide the [table information](https://github.com/pingcap/tidb/blob/v8.5.0/pkg/executor/builder.go#L791), the lock was [skipped](https://github.com/pingcap/tidb/blob/v8.5.0/pkg/executor/select.go#L252) during execution.

The second select uses point-get with lock flag, it tried to lock the row and was blocked by t1.

### 4. What is your TiDB version? (Required)

v8.5.0