fix: god account type 5->6 in schema.sql and add migration

[Zbizu]

Description

god account has wrong account type in schema, this PR fixes that

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I checked the PR checks reports
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works

Summary by CodeRabbit

• Chores
  • Bumped database schema version and added a migration to apply the update.
  • Adjusted the default GOD account type from 5 to 6 to align with the updated schema.

---

Note: No user-facing changes in this release.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a migration and updates seed data: schema.sql increments db_version to 54 and changes the initial GOD account type from 5 to 6; a new migration (data-otservbr-global/migrations/54.lua) updates existing accounts with type=5 to type=6.

Changes

Cohort / File(s)	Summary
Database schema seed schema.sql	db_version changed from '52' to '54'; initial GOD account type changed from 5 to 6.
Database migration script data-otservbr-global/migrations/54.lua	New migration onUpdateDatabase() added: logs start, executes UPDATE accounts SET type = 6 WHERE type = 5, returns false and logs on failure, returns true on success.

Sequence Diagram(s)

sequenceDiagram
  participant Migrator
  participant Logger
  participant Database

  Migrator->>Logger: log("Starting DB update: 54")
  Migrator->>Database: execute("UPDATE accounts SET type=6 WHERE type=5")
  Database-->>Migrator: result (success / affected rows / error)
  Migrator->>Logger: if error -> log("Migration 54 failed: ...")
  Migrator->>Logger: else -> log("Migration 54 completed")
  Migrator-->>Migrator: return boolean success

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I hopped through rows and changed a five,
Gently nudged the schema to fifty‑four alive.
A tiny script, a quiet tweak,
Now accounts stand straighter on their new peak. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: updating the god account type from 5 to 6 in schema.sql and adding a migration script, which aligns with both the file changes and PR objectives.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@data-otservbr-global/migrations/54.lua`:
- Around line 1-12: The migration's UPDATE in onUpdateDatabase is targeting type
= 5 (ACCOUNT_TYPE_COMMUNITYMANAGER) but the intent was to change god accounts —
inspect src/enums/account_type.hpp to confirm the numeric value for
ACCOUNT_TYPE_GOD and either (a) change the WHERE clause in the UPDATE accounts
SET type = 6 WHERE type = 5; to use the correct source value for god (e.g. WHERE
type = <ACCOUNT_TYPE_GOD>) or (b) if the intent was to upgrade community
managers to god then update the migration comment to reflect that and leave the
query, or better yet change the target value to the correct enum constant;
update the SQL query in onUpdateDatabase (and the logger message) to match the
chosen correct mapping and add a safety check/backup step before running
destructive changes.

[Zbizu]

LGTM
(can't approve my own pr)