fix: drop unused oauth_tokens table from 003 (closes #97)

[rsharath]

Summary

Closes #97. Removes the never-wired oauth_tokens table directly from migrations/003_oauth_clients.up.sql (and the matching DROP statements from the down file), instead of layering a separate drop migration on top.

Approach changed mid-PR (per @saucam's review)

The original commit added 015_drop_oauth_tokens.{up,down}.sql. Saucam asked: "can we just drop these directly without adding a new migration?" — and in this case, yes: ZeroID has not been deployed to any persistent environment yet, so every install runs migrations from scratch on the current SQL. Editing 003 in place produces the same end state everywhere.

If/when a real deployment exists, future cleanups of unused tables MUST use the layered-migration pattern. Migration files become append-only the moment any deployment runs them, because schema_migrations.version says "this version was applied" while the actual rows behave however the contemporaneous SQL dictated. Two deployments at the same migration_version with different SQL = silent schema divergence.

Diff

• migrations/003_oauth_clients.up.sql — removed the CREATE TABLE oauth_tokens block and its four CREATE INDEX statements (idx_oauth_tokens_jti, _client_id, _expires_at, _tenant). Header comment updated.
• migrations/003_oauth_clients.down.sql — removed the corresponding DROP INDEX / DROP TABLE statements.

Net: 2 files changed, 1 insertion(+), 36 deletions(-).

Verified

$ grep -rn "oauth_tokens" --include="*.go" .
$ grep -rn "OauthToken\|OAuthToken" domain/ internal/

Zero hits in either. No Go domain model binds to the table; no repository references it.

Test plan

• go vet ./... — clean
• Full integration suite green ~10s. Migrations run fresh in the testcontainer on every test run, so this exercises the trimmed 003 end-to-end (no oauth_tokens is ever created).

[gemini-code-assist]

Code Review

This pull request removes the unused oauth_tokens table and its associated indexes, providing both an upgrade and a rollback migration. Feedback indicates that the up migration contains redundant DROP INDEX statements since PostgreSQL's DROP TABLE automatically removes associated indexes. Additionally, the down migration includes a redundant index on the jti column, which is already covered by a UNIQUE constraint.

[saucam]

@rsharath can we just drop these directly without adding a new migration ?

[rsharath]

You're right — I had the wrong context. Reversed the previous decision and pushed the cleaner approach (8915786):

• Reverted 015_drop_oauth_tokens.{up,down}.sql.
• Edited 003_oauth_clients.{up,down}.sql directly to remove the oauth_tokens block.

Net diff: 2 files changed, 1 insertion(+), 36 deletions(-) — smaller and clearer.

Caveat written into the commit message: this only works because no deployment has run 003 yet. Once a real deployment exists, the same cleanup would need a layered drop migration to avoid schema divergence (two deployments at migration_version=3 with different SQL produce silent disagreement).

Title + body updated to reflect the new approach. CI re-running.