Array of `super` is still accepted as a type in some contexts and triggers and ICE in `abi.decode()`

## Description

Error:
```
Internal compiler error:
/solidity/libsolidity/ast/Types.cpp(1982): Throw in function virtual solidity::frontend::TypeResult solidity::frontend::ArrayType::interfaceType(bool) const
Dynamic exception type: boost::wrapexcept
std::exception::what: Expected detailed error message!
[solidity::util::tag_comment*] = Expected detailed error message!
```

**Note: This bug was reported in https://github.com/ethereum/solidity/issues/8280 and marked as completed in 2020. However, it still exists in the latest release (v0.8.28), hence this report.**

## Environment

- Compiler version: Version: 0.8.28-develop.2025.1.19+commit.7893614a.mod.Linux.g++
- Compilation pipeline (legacy, IR, EOF):
- Target EVM version (as per compiler settings):
- Framework/IDE (e.g. Foundry, Hardhat, Remix):
- EVM execution environment / backend / blockchain client:
- Operating system: Ubuntu 22.04

## Steps to Reproduce

poc.sol (fuzzer-generated):
```solidity
contract test {
struct S {
uint8[] a;
string[2] b;
}

S[][] s1;
S[][1] s2;
S[1][] s3;

function f(bytes calldata data)
external
pure
returns (uint256[2][3] memory)
{
return abi.decode(data, (super[3]));
}

function test2(S[][1] memory _a) public returns (S[][1] memory) {}

function f(uint[2] memory) public pure {}
}
```

To reproduce:
`solc --bin -o poc poc.sol`

Start with libsolidity/ast/Types.cpp at the reported line 1982 and trace how abi.decode() handles the super[3] type in poc.sol. Reproduce with solc --bin -o poc poc.sol, then verify that the invalid array-of-super usage produces a diagnostic rather than an internal compiler error.

Written by the indexing model from the issue text.