RemainingSeconds is the same for all codes in same time step.

Why does generating a new code within the same time step but with a different key not have a new RemainingSeconds?

If I call GetTotp two times with a step of 9 minutes, the second call has a RemainingSeconds of the first call.

GetTotp takes a byte[] and count, 1, 2, 3, etc. the byte[] key is a hashed salt and count which generates a new code. I found that I had to make the key more unique than the previous call to GetTotp because calling GetTotp again (like when user wants a new key) within the 9 minute step just returned the same code.

Example. time step is 540 seconds.

>GetTotp(salt, 1);
> "309960"
> RemainingSeconds 539

wait some seconds and call again...

>GetTotp(salt, 2);
> "718933"
> RemainingSeconds 460

I expected RemainingSeconds to be closer to 539

```
internal string GetTotp(byte[] salt, int count)
{
string saltedKey = HashSomeStringWithSalt(salt, count.ToString());
byte[] key = Convert.FromBase64String(saltedKey);

var totp = new Totp(key, step: 540, mode: OtpHashMode.Sha256, totpSize: 6);

var dateTimeNow = DateTime.UtcNow;
var totpCode = totp.ComputeTotp(dateTimeNow);
return totpCode;
}

internal int GetOTPRemainingSeconds(byte[] salt, int count)
{
string saltedKey = HashSomeStringWithSalt(salt, count.ToString());
byte[] key = Convert.FromBase64String(key);
var totp = new Totp(key, step: 540, mode: OtpHashMode.Sha256, totpSize: 6);

return totp.RemainingSeconds();
}

```

Reproduce the two GetTotp calls using the same salt, a 540-second step, and counts 1 and 2, then compare their values with GetOTPRemainingSeconds. Inspect how the Totp instance calculates RemainingSeconds versus ComputeTotp; done means confirming whether the shared time-step result is expected and resolving the reported mismatch.

Written by the indexing model from the issue text.