Operator can skew the state of the `Core` contract and be considered as staked for a DSS, even though the operator is not registered with that DSS on the `Core`.
Audit: 2024-07-karak-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/Operator.sol#L20
https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/Operator.sol#L21
https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L130-L141
https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L113-L124
https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L146-L153


# Vulnerability details

## Impact

A lack of verification on the `Core::finalizeUpdateVaultStakeInDSS()` function permit an operator to abuse it and can make a vault considered as staked for the DSS even though the operator is not registered with this DSS. Potentially let the DSS send rewards on a vault for which the operator is not registered with this DSS.

## Proof of Concept

We are interested in two different states in the `Core` contract: 

The [dssMap](https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/Operator.sol#L20) by operator represent the dss registered for the operator.
And the [vaultStakedInDssMap](https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/Operator.sol#L21) which represent the vault staked in DSS.

Look at this scenario: 
- An operator is registered on a DSS and have no vault considered as staked on that DSS.
- The operator now [call](https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L130-L141) `Core::requestUpdateVaultStakeInDSS()` to create a request to stake one of its vaults in the DSS.
- In waiting the delay to finalize the state update of staked vault, the operator [call](https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L113-L124) `Core::unregisterOperatorFromDSS()` and directly the operator is unregistered from the DSS.
- When delay is passed, he can [call](https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/Core.sol#L146-L153) `Core::finalizeUpdateVaultStakeInDSS()` and because the function not verify if the operator is already registered with the DSS, the call goes through and the state become skew.

This offset in this two state can be problematic on the DSS side, the `Core::finalizeUpdateVaultStakeInDSS()` function call a hook on the DDS if it implement one for his internal logic and state update. It can create a skewstate for the DSS and the operator can take advantage on it, e.g the vault can be considered as staked on the DSS and therefore receive reward from the DSS, but is not officially considered like this in the `Core` contract because the operator is not registered to the DSS. 

### Poc

You can add this PoC to the `./test/nativeRestaking/nativeVault.t.sol` :

```sol