chore(jobs): renomeia display "Aprendiz" -> "Novato"

DA_Job_Novice DisplayName e docs de arquitetura (3 ARQUITETURA*.md)
sincronizados com a nova terminologia PT-BR. Server (Novice.json +
JobsDatabase.cpp) sera commitado separado no repo do ZeusServerEngine.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ARQUITETURA.md

@@ -9,7 +9,7 @@
 
 > **Extensões da arquitetura** (documentos normativos paralelos, escopo específico):
 > - [`ARQUITETURA_SERVER_SELECT.md`](ARQUITETURA_SERVER_SELECT.md) — Server Select, lista de mundos, handoff CharServer↔WorldServer, multi-region, queue, Valkey. Roadmap em 7 fases.
-> - [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md) — Stats primários (STR/AGI/VIT/INT/DEX/LUK), classes (Aprendiz → especializações), fórmulas de stats derivados (ATK/MATK/DEF/...), `jobs.yml` data-driven, stat allocation server-side. Espelha rathena.
+> - [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md) — Stats primários (STR/AGI/VIT/INT/DEX/LUK), classes (Novato → especializações), fórmulas de stats derivados (ATK/MATK/DEF/...), `jobs.yml` data-driven, stat allocation server-side. Espelha rathena.
 
 > **Sumário de mudanças (2026-05-11):** adicionada secção de **temas sazonais
 > de UI** (`UI/Themes/`), com tutorial §4.7, regra de "no hard ref a textura

ARQUITETURA_CHARACTER_MODEL.md

@@ -6,7 +6,7 @@
 
 ## Context
 
-O ZMMO usa modelo de atributos estilo Ragnarok Online — 6 stats primários que o jogador aloca pontos (STR/AGI/VIT/INT/DEX/LUK), com stats derivados calculados a partir deles + level + classe + equip. Jogador nasce **Aprendiz** (Novice) e especializa em outras classes ao chegar a critérios (job level + quest de mudança).
+O ZMMO usa modelo de atributos estilo Ragnarok Online — 6 stats primários que o jogador aloca pontos (STR/AGI/VIT/INT/DEX/LUK), com stats derivados calculados a partir deles + level + classe + equip. Jogador nasce **Novato** (Novice) e especializa em outras classes ao chegar a critérios (job level + quest de mudança).
 
 Este doc fixa:
 1. O que persiste no MySQL (CharServer) vs o que vive em memória (WorldServer).
@@ -58,10 +58,10 @@ Padrão rathena: `db/re/job_stats.yml` carregado no boot. Hot-reloadable.
 
 | Componente | Quem decide | Quem persiste |
 |---|---|---|
-| Criar char (stats iniciais, class=Aprendiz) | CharServer (valida) | CharServer → MySQL |
+| Criar char (stats iniciais, class=Novato) | CharServer (valida) | CharServer → MySQL |
 | Stat allocation (gastar `status_point` em STR/etc.) | CharServer **ou** WorldServer | CharServer → MySQL (via writeback) |
 | Subir de level / ganhar EXP | WorldServer (kill mob, quest) | WorldServer → writeback → CharServer → MySQL |
-| Mudar classe (Aprendiz → Espadachim) | WorldServer (cumpre quest) | WorldServer → writeback → CharServer → MySQL |
+| Mudar classe (Novato → Espadachim) | WorldServer (cumpre quest) | WorldServer → writeback → CharServer → MySQL |
 | Recalcular ATK/MATK/DEF/etc. | WorldServer (memória, toda hora) | NÃO persiste |
 | Casting de skill | WorldServer | NÃO persiste (efêmero) |
 | Resultado de skill (HP perdido, item dropado) | WorldServer | WorldServer → writeback |
@@ -260,7 +260,7 @@ version: 1
 jobs:
   - id: 0
     name: Novice              # nome técnico (inglês, estável)
-    display_name_ptbr: Aprendiz
+    display_name_ptbr: Novato
     parent_job: null
     max_base_level: 99
     max_job_level: 10
@@ -322,7 +322,7 @@ jobs:
 
 ## 5. Fluxos
 
-### 5.1 Criação de personagem (Aprendiz)
+### 5.1 Criação de personagem (Novato)
 
 ```
 Cliente → C_CHAR_CREATE { name, world_id, class_id=NOVICE, appearance }
@@ -342,7 +342,7 @@ CharServer:
   4. → S_CHAR_CREATE_OK
 ```
 
-**Nota:** o player **sempre** nasce Aprendiz. Outras classes só via job change in-game (Fase pós-Fase 3).
+**Nota:** o player **sempre** nasce Novato. Outras classes só via job change in-game (Fase pós-Fase 3).
 
 ### 5.2 Stat allocation (após level up)
 
@@ -377,7 +377,7 @@ WorldServer (em kill mob / complete quest):
 
 Mesmo padrão pra job_exp/job_level (com skill_point em vez de status_point).
 
-### 5.4 Job change (Aprendiz → Espadachim, etc.)
+### 5.4 Job change (Novato → Espadachim, etc.)
 
 ```
 WorldServer (player cumpriu quest):
@@ -571,13 +571,13 @@ Audit log entries (Fase 3 do ServerSelect doc): toda mudança de zeny>1000, leve
 
 ## 8. Roadmap de implementação
 
-### Fase A — Schema + criação de char Aprendiz (parte da Fase 1 do ServerSelect)
+### Fase A — Schema + criação de char Novato (parte da Fase 1 do ServerSelect)
 
 - Schema `characters` com todos os campos (já especificado no `ARQUITETURA_SERVER_SELECT.md`).
-- `jobs.yml` apenas com `Novice` (Aprendiz) — outras classes ficam pra B.
+- `jobs.yml` apenas com `Novice` (Novato) — outras classes ficam pra B.
 - CharServer carrega `jobs.yml` no boot.
 - `C_CHAR_CREATE` valida `class_id == NOVICE` e usa defaults do yml.
-- Cliente UI: tela de criação com nome + appearance (sem stat allocation aqui — Aprendiz nasce com todos os stats=1).
+- Cliente UI: tela de criação com nome + appearance (sem stat allocation aqui — Novato nasce com todos os stats=1).
 
 ### Fase B — Classes adicionais + job change
 
@@ -628,7 +628,7 @@ Audit log entries (Fase 3 do ServerSelect doc): toda mudança de zeny>1000, leve
 1. **Stats primários flat** na tabela `characters` (str/agi/vit/int/dex/luk + level/exp + hp/sp/max_hp/max_sp + status_point/skill_point + zeny + class_id). **Sem entidade separada.**
 2. **Stats derivados NUNCA persistidos** — sempre recalculados em runtime no WorldServer (`StatusCalc::ComputeAll`).
 3. **Jobs data-driven** via `Server/ZeusCharServer/data/jobs.yml` (versionado no git, hot-reloadable). `characters.class_id` é lookup lógico.
-4. **Player nasce Aprendiz** (`class_id=NOVICE`); especialização via quest in-game (Fase B).
+4. **Player nasce Novato** (`class_id=NOVICE`); especialização via quest in-game (Fase B).
 5. **Stat allocation acontece no WorldServer** (não CharServer). Validação `cost = (s-1)/10 + 2` server-side.
 6. **Anti-cheat:** toda mudança de estado é server-authoritative. Cliente apenas renderiza.
 7. **Fórmulas espelham rathena** (`status_calc_pc_` em `src/map/status.cpp:4996`) — adapta valores pra balanceamento Zeus depois.

ARQUITETURA_SERVER_SELECT.md

@@ -311,11 +311,11 @@ ALTER TABLE characters
 **Notas:**
 - `world_id` é nullable (sem chars em prod hoje — evita downtime futuro). Validação no service: novos chars devem ter `world_id`.
 - Estrutura flat segue rathena (`.bases/rathena/rathena-master/sql-files/main.sql:209-296`) — padrão da indústria emuladora. Sem entidade `character_stats` separada (1:1 FK seria JOIN inútil).
-- Defaults vêm da row Aprendiz no `jobs.yml` (ver doc Character Model).
+- Defaults vêm da row Novato no `jobs.yml` (ver doc Character Model).
 - **Stats derivados (ATK/MATK/DEF/MDEF/hit/flee/crit/aspd) NÃO entram aqui** — são sempre recalculados em runtime no WorldServer via fórmulas. Persistir é bug fest (esquece atualizar quando muda equip/buff/level).
 - `version` (optimistic locking) usado em writeback da Fase 3.
 
-> **Para o detalhamento do modelo de personagem** (stats primários vs derivados, fórmulas de ATK/MATK/DEF, jobs.yml, stat allocation, leveling curve, classes Aprendiz → especialização), ver doc dedicado [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md).
+> **Para o detalhamento do modelo de personagem** (stats primários vs derivados, fórmulas de ATK/MATK/DEF, jobs.yml, stat allocation, leveling curve, classes Novato → especialização), ver doc dedicado [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md).
 
 ### Schema Valkey (Fase 2+)