Authentication forms rely on implicit auth side effects instead of explicit success gating

### Description

Some authentication-related forms in the frontend advance UI state immediately after invoking authentication operations, without explicitly gating those transitions on successful completion of the underlying auth action.

This behavior makes the frontend tightly coupled to implicit side effects inside AuthContext (such as navigation, token setting, or error state updates). When auth behavior changes, fails, or is refactored (as in recent AuthContext updates), this can result in false-positive success flows and incorrect UI state.
This issue is frontend-specific and exists independently of backend correctness, SMTP, OAuth credentials, or environment configuration.
### Affected Components
`OTPVerificationForm`
`ResetPasswordForm`

### File:
frontend/src/Pages/Authentication/forms.tsx
### Root Cause (Code-Level)
Authentication forms invoke auth methods and then immediately trigger success-related UI transitions without explicitly confirming that the auth operation completed successfully.

Examples of this pattern:
- Advancing OTP verification flow immediately after calling email verification
- Advancing password reset completion immediately after calling reset and login operations

This design assumes that auth methods will always handle failures internally in a way that prevents UI progression, which makes the frontend fragile and dependent on implicit behavior inside AuthContext.

Changes to auth behavior or refactors in AuthContext make this coupling more visible and error-prone.

### Examples
OTP verification flow
```
await verifyEmail(email, otp);
handleOtpVerified();
```
The UI advances without explicitly gating on successful verification.

### Password reset flow
```
await confirmForgotPassword(email, code, newPassword);
await login(email, newPassword);
handlePasswordReset();
```

If either operation fails, the UI may still proceed as if the reset and login succeeded.

### Expected Behavior
Authentication forms should advance UI state only after successful completion of the relevant auth operation

_Failure cases should:_
1. Stop the UI flow
2. Surface existing error state
3. Avoid false-positive success UI

### Actual Behavior
- UI progression is not explicitly gated on auth success
- Success transitions rely on implicit side effects inside AuthContext
- Changes to auth logic or failure handling can lead to incorrect frontend state

### Scope
- Frontend only
- Limited to authentication form components
- No backend changes required
- No assumptions about how AuthContext internally signals success or failure

### Proposed Fix
1. Explicitly gate success-sensitive UI transitions in authentication forms (e.g. using try/catch or equivalent success checks), ensuring UI state advances only when auth operations complete successfully, while relying on existing error handling for failure cases.

2. This decouples frontend correctness from implicit auth side effects and makes the auth flow robust against future changes in auth logic, configuration, or OAuth integration.

### Why This Matters
1. Prevents false-positive success flows
2. Improves frontend correctness and debuggability
3. Makes upcoming work on Google Sign-In, environment configuration, and auth refactors safer
4. Reduces tight coupling between forms and AuthContext internals

### Final note
This issue focuses purely on frontend control flow correctness and is intentionally independent of backend, OAuth credentials, or environment setup