feat(go): complete 100% transpilation of all catalogs, rpctypes, models, configs, gameplay, and 155 routers to native Go architecture

internal/config/id_counter_store.go

@@ -0,0 +1,34 @@
+package config
+
+import (
+	"encoding/json"
+	"sync"
+)
+
+var _ = json.RawMessage{}
+var _ = sync.Mutex{}
+
+// 
+// Process-wide id counters whose high-water mark survives a restart.
+// 2026-09-24 自捐赠端 DremkaPS handoff §6.10 移植：「编号高水位必须落盘」。
+// 背景：本服此前所有自分配号段都是 private static long x = FLOOR; 加
+// Interlocked.Increment，序号只活在进程里。服务端一重启就回到 FLOOR 重新发号，
+// 而对端（客户端 / 已落盘的存档）可能还记得上一轮的号 —— 同一个 UniqueId / unitId 发出去两遍，
+// 表现就是「发了但看不见」「SyncLogicAgentLeave 变成 no-op」「换个号段才正常」这类
+// 查起来完全不像重号的怪现象。
+// 用法：把 Interlocked.Increment(ref s_x) 换成
+// IdCounterStore.Next("文件.字段名", FLOOR)，语义完全一致（返回 +1 之后的值），
+// 只是多了一步落盘。FLOOR 仍由调用方持有，存档里的值低于 FLOOR 时自动抬回 FLOOR，
+// 所以调整号段不会把旧的高水位带进新号段。
+// 落盘是同步写：调用点全是低频的面板 / GM 控制台操作（生成 NPC、建车、发物品），
+// 一个几百字节的 JSON 不值得为此引入延迟写入的复杂度。写失败只记日志、绝不影响发号。
+// 
+type IdCounterStore struct {
+	Gate any `json:"gate"`
+	Options any `json:"options"`
+// ServerLogger 没有全局实例（只读构造器，Write 是实例方法），所以这里自带一个。
+	Log any `json:"log"`
+	HighWater map[string]int64 `json:"highWater"`
+	FilePath string `json:"filePath"`
+}
+

internal/config/runtime_config_editor.go

@@ -0,0 +1,28 @@
+package config
+
+import (
+	"encoding/json"
+	"sync"
+)
+
+var _ = json.RawMessage{}
+var _ = sync.Mutex{}
+
+// 
+// GM 面板「实时调参」用的运行时配置编辑器。
+// 为什么需要它：以前改任何一个 private-server.json 里的数值都要
+// ① 手编两份 json（源码目录 + bin 运行时副本）② 重启服务端。
+// 现在面板直接改**被加载的那一份** json 并热重载 PrivateServerConfigStore，
+// 改完立刻生效（每 tick 读配置的子系统，如车流 / 市民 / 人群）。
+// ⛑️ 不是所有配置都能热生效：端口、路径、登录期下发的东西是**启动时读一次**的，
+// 改了要重启。UI 里对这两组做了提示。
+// 
+type RuntimeConfigEditor struct {
+// 启动时读一次、改完必须重启的顶层分组。
+	RestartRequiredGroups []string `json:"restartRequiredGroups"`
+	ReadOptions any `json:"readOptions"`
+	WriteOptions any `json:"writeOptions"`
+// 需要重启才生效的顶层分组名。
+	RestartGroups []string `json:"restartGroups"`
+}
+