[flang] Non-POINTER LHS not diagnosed when the RHS of a pointer assignment is a restricted specific intrinsic

When the right-hand side of a pointer assignment is a *restricted* specific intrinsic, flang reports only the RHS error and never diagnoses that the left-hand side is not a pointer. For every other invalid-RHS shape I tried, flang does diagnose the LHS.

Reproducer (current main, `afdcd7f828b2`):

```fortran
subroutine s
u => amin0
end subroutine
```

```
$ flang -fsyntax-only repro.f90
error: Semantic errors in repro.f90
repro.f90:2:8: error: 'amin0' is not an unrestricted specific intrinsic procedure
u => amin0
^^^^^
```

Nothing is said about `u`, which is implicitly typed REAL and has no POINTER attribute — a violation of F2023 C1024 (data-pointer reading) / C894 (procedure-pointer reading) independent of what the RHS is. A user who fixes the `amin0` complaint only discovers the LHS problem on the next compile.

The LHS check itself exists and fires for other RHS shapes. With an unrestricted specific intrinsic as the target, flang reports both sides:

```fortran
subroutine s
u => cos
end subroutine
```

```
repro2.f90:2:3: error: The left-hand side of a pointer assignment is not definable
u => cos
^^^^^^^^
repro2.f90:2:3: because: 'u' is not a pointer
...
repro2.f90:2:3: error: In assignment to object pointer 'u', the target 'cos' is a procedure designator
```

The same LHS diagnosis appears for a declared non-pointer LHS (`real :: u` then `u => cos`), a data RHS (`u => v`), and an external-procedure RHS (`u => f`) — the restricted-specific RHS seems to be the only shape where it is suppressed, presumably because the failed analysis of the RHS designator stops the pointer-assignment checks (including LHS definability) from running at all.

For comparison, gfortran 16.1 (`Error: Non-POINTER in pointer association context (pointer assignment)`) and ifx 2026.1 (`error #6793: The POINTER attribute is required. [U]`) both lead with the LHS diagnostic on this reproducer.

Related: the `u => llt` case from #208825 currently crashes; once #217852 lands it will produce the same single RHS-only error as `u => amin0` above, so it joins this class.

Start by running the provided `flang -fsyntax-only` reproducer and compare it with the unrestricted `cos` case, the declared non-pointer case, and the data or external-procedure RHS cases. Trace the pointer-assignment semantic analysis to find why a restricted specific intrinsic RHS prevents the existing LHS check; done means the `amin0` case reports both the non-POINTER LHS and RHS errors without regressing the other cases.

Written by the indexing model from the issue text.