feat: remove enableSessionKeepAlive flag

[sricharan-varanasi]

📝 Description

🔗 Jira Ticket M2-#

Stacked on #2251. Removes enableSessionKeepAlive and makes its on-behaviour permanent.

Changes include:

• Keep-alive engine runs on isAuthorized alone
• Session adoption runs on !refreshToken alone
• Flag removed from the type, the defaults, and the test setup

Behaviour is unchanged: both gates were flag && x, and with the flag on that was already just x.

✏️ Notes

• The deleted flag-off engine test was the only cover for if (!isAuthorized) return;, so it's repurposed rather than dropped.
• 4159 tests pass, eslint 0 errors, tsc clean.

✅ Checklist

Functionality

• The feature behaves correctly in practice and fulfills the intended business purpose
• The implementation accounts for edge cases, avoids subtle logical errors, and handles somewhat rare failure states (e.g. offline mode for mobile, 3rd party being down, etc)

Testing

• Verify there are automated tests added that meaningfully cover critical behavior and failure cases
• Code coverage does not go down as result of this change
• Test suite passes

Security & Data Privacy

• Verify there is no chance we would accidentally log PII to application logs
• Verify this addition does not materially affect our security attack surface, and if so it has undergone security review
• All inputs are sanitized
• New dependencies are well maintained, have significant justification for being added to the project, and are documented in the Curious open source credit page

Logging/Monitoring

• Logging is implemented for this change such that you could troubleshoot this feature in production
• The change/feature is able to be monitored in production

Performance

• This change does not introduce n+1 queries or other performance issues within our expected scale (e.g. missing indexes on frequently queried columns, frequently updating tables that are accessed often)

Readability

• All commented out code is removed
• Debugging code including extraneous log lines are removed
• Code is easy to understand through naming and structure; comments explain intent or non‑obvious decisions

Change Safety

• Backend changes are backwards compatible with old clients, or it is well known they are not and a deployment/rollout plan is in place. This include backend changes being compatible with old mobile app versions, as well as applet versioning within Curious.
• Destructive database migrations are rolled out in stages. For example, renaming a column means adding a new column and migrating the existing data to that columns in one deployment. Then monitoring to ensure that field isn't used, and finally removing that old column in a separate deployment.