Track Nakama runtime UUID helper migration

[JOY]

Context

Gemini review on PR #8 suggested replacing prototype Math.random() ID suffixes in Nakama runtime helpers with Nakama's platform UUID generation, likely nk.uuidV4().

Current state

newMemoryId(context) and newActivityId(context) currently build IDs from:

• prefix (mem / act)
• sanitized player id
• timestamp
• Math.random() suffix
• current bounded-list sequence

The local backend/nakama/types/nakama-runtime.d.ts shim does not expose uuidV4() yet, and the current ID helpers do not receive nk, so this is broader than the PR #8 behavioral fixes.

Proposed follow-up

• Verify Nakama OSS runtime API support for UUID generation in the exact runtime version used by the project.
• Add the method to the local TypeScript shim if available.
• Thread nk into ID generation helpers or introduce a small newRuntimeId(prefix, context, nk) helper.
• Keep IDs deterministic enough for test harness assertions where needed.
• Re-run npm run build && npm test in backend/nakama.

Non-goals

• Do not weaken storage version checks.
• Do not change the agent activity log cap or runtime counter semantics.
• Do not let these IDs become authoritative gameplay identifiers.

Related

• PR feat(nakama): persist agent runtime activity #8: feat(nakama): persist agent runtime activity #8
• Follow-up to Gemini review comment around nk.uuidV4().