eth_getAccount and eth_getAccountInfo still accept missing block params

[peter941221]

1. Observed behavior

eth_getAccount and eth_getAccountInfo still treat the block parameter as optional.

Both methods accept calls with only the address argument and silently fall back to the default block selection path, while the surrounding required-block-parameter family already returns a geth-style invalid params error at binding time.

2. Evidence

Interface signatures still make the second argument optional:
src/Nethermind/Nethermind.JsonRpc/Modules/Eth/IEthRpcModule.cs
eth_getAccount(..., BlockParameter? blockParameter = null)
eth_getAccountInfo(..., BlockParameter? blockParameter = null)

The implementation also accepts nullable block parameters:
src/Nethermind/Nethermind.JsonRpc/Modules/Eth/EthRpcModule.cs
eth_getAccount(Address accountAddress, BlockParameter? blockParameter)
eth_getAccountInfo(Address accountAddress, BlockParameter? blockParameter)

Both methods then flow into the shared header lookup helper:
src/Nethermind/Nethermind.JsonRpc/Modules/BlockFinderExtensions.cs
SearchForHeader(this IBlockFinder blockFinder, BlockParameter? blockParameter, bool allowNulls = false)

Inside that helper, Nethermind does:
blockParameter ??= BlockParameter.Latest;

That is why omitting the second argument currently succeeds and silently falls back to the default block selection path instead of failing at binding time.

Current tests on upstream/master also lock in the permissive behavior:
src/Nethermind/Nethermind.JsonRpc.Test/Modules/Eth/EthRpcModuleTests.cs
Eth_get_account_no_block_argument
Eth_get_account_info_no_block_argument

The shared JsonRpc binding path already has the required-argument behavior we want:
src/Nethermind/Nethermind.JsonRpc/JsonRpcService.cs
missing value for required argument N

Existing binding-level examples:
src/Nethermind/Nethermind.JsonRpc.Test/JsonRpcServiceTests.cs
eth_getBlockByNumber with no args -> missing value for required argument 0
eth_feeHistory with the last arg omitted -> missing value for required argument 2

3. Local reproduction on current upstream/master

eth_getAccount with the block argument omitted currently succeeds and returns account data.

eth_getAccountInfo with the block argument omitted currently succeeds and returns account data.

After changing the method signatures to require BlockParameter instead of BlockParameter?, both methods move onto the existing binding-time required-argument path:

omitted block argument -> missing value for required argument 1
explicit null block argument -> missing value for required argument 1

4. Validation from a local patch on current upstream/master

dotnet test src\Nethermind\Nethermind.JsonRpc.Test\Nethermind.JsonRpc.Test.csproj --filter "Name=Eth_get_account_no_block_argument_returns_invalid_params|Name=Eth_get_account_explicit_null_block_argument_returns_invalid_params|Name=Eth_get_account_found|Name=Eth_get_account_incorrect_block|Name=Eth_get_account_info_no_block_argument_returns_invalid_params|Name=Eth_get_account_info_explicit_null_block_argument_returns_invalid_params|Name=Eth_get_account_info_found|Name=Eth_get_account_info_incorrect_block"

Result:
8 total, 8 passed

Extra binding regression for explicit null:

dotnet test src\Nethermind\Nethermind.JsonRpc.Test\Nethermind.JsonRpc.Test.csproj --filter "Name=ExplicitMissingTypedArgumentToken"

Result:
1 total, 1 passed

5. Suggested fix

Require the second parameter in both eth_getAccount and eth_getAccountInfo by signature, then cover both omitted and explicit null block arguments on the RPC response path.