Improve type safety using JSDocs

[koenigstag]

Summary

Introduces JSDoc type annotations across the codebase and enables JS type checking (checkJs) via the TypeScript compiler, without converting the project to TypeScript. The goal is to catch type errors at build time while keeping plain .js runtime.

Along the way this PR also fixes several real type-level bugs uncovered by the checker and does some structural refactoring of the packet layer.

~195 files touched (+2988 / −1295), mostly mechanical JSDoc additions.

Tooling

• Add jsconfig.json with checkJs, allowJs, module/moduleResolution: nodenext, noEmit.
• Add build script: tsc --project jsconfig.json (type-check only, no emit).
• Add dev dependencies: typescript, @types/node.

What changed

• JSDoc types across core/: Models, Managers, states, Handlers, Systems, Events, and both client and server packet layers are annotated with @param / @returns / @type and shared @typedefs.
• Client packets: typed payload reads and handlers.
• Server packets: typed, plus refactored class inheritance to share a common base and reduce duplication.
• InitialParametersManager: updateParams refactored.
• datapack/ai/: NPC AI scripts annotated.

New files

• jsconfig.json — type-check configuration.
• enums/classIdsEnum.js — class-name → classId map.
• database/sql/init_db.sql — schema bootstrap for local testing (gameservers, object_id_registry, scheduled_tasks, characters, items, skills).

Notes

• This is type-checking only — there is no runtime/behavior change expected from the JSDoc additions. Behavioral changes are limited to the explicit refactors above.
• Type checking is not yet clean — see the build-status comment below for the remaining errors and where they are concentrated.

[koenigstag]

Build status (npm run build → tsc --project jsconfig.json)

Type checking currently reports 91 errors after fixes. The project is not yet type-clean; remaining errors are concentrated in the AI/combat state machine and a few packet/manager spots.

By file (top):

File	Errors
core/states/CastState.js	14
core/states/AttackState.js	11
core/states/PickupState.js	8
core/states/IdleState.js	8
core/states/FollowState.js	8
core/clientPackets/RequestMagicSkillUse.js	6
core/Models/Player.js	6
core/Managers/EntitiesManager.js	5
core/Managers/VisibilityManager.js	4
(others)	1–2 each

By error kind (top):

Code	Count	Meaning
TS2339	44	Property does not exist on type
TS2345	11	Argument type not assignable to parameter
TS2322	11	Type not assignable
TS18048	7	Value is possibly undefined
TS2554	6	Wrong number of arguments
TS2533	5	Object is possibly null/undefined
TS18047	4	Value is possibly null

Most TS2339 cases come from the core/states/* chain operating on loosely-typed entities; the null/undefined family (TS18048/18047/2533) is mostly missing guards. None of these block runtime — build is noEmit type-check only.