feat(net,runtime): Campaign CC CC2 — CharacterCreate wire, 0xF643 correlation, creation status events

Wire (Core.Net):
- CharacterCreate.cs: outbound 0xF656 builder, byte-exact port of
  Proto_UI::SendCharGenResult@0x00546a70 -> ACCharGenResult::Pack@0x005c7570
  -> CG_Pack@0x005c7200. Account String16L first (packed outside CG_Pack),
  then the constant-1 u32, heritage/gender, 14 appearance strip/style/color
  u32s, 6 f64 shades (skin/hair/headgear/shirt/trousers/footwear, retail
  order), template, 6 attributes, slot, classId, numSkills + exactly 55
  u32 skill-advancement classes (ReadOnlySpan validated ==55, throws
  ArgumentException otherwise — ACE terminates the session on any other
  count via PlayerFactory.CreateResult.ClientServerSkillsMismatch), name
  String16L, startArea, isAdmin, isEnvoy, and a trailing checksum whose
  exact 19-term accumulation set (heritage+gender+3 strips+hairColor+
  eyeColor+hairStyle+headgearStyle+shirtStyle+trousersStyle+footwearStyle+
  template+6 attributes) is read byte-for-byte off CG_Pack's decompiled
  accumulator (0x005c7213-0x005c74c3) — headgearColor/shirtColor/
  trousersColor/footwearColor/shades/slot/classId are deliberately absent
  from the sum despite sitting adjacent on the wire. Cross-checked against
  ACE's CharacterCreateInfo.Unpack/Appearance.Unpack and holtburger's
  CharacterCreateRequestData (types.rs:236-369), which agree on every
  field and order. Retail routes via SendToLogon — the same queue
  CharacterDelete already uses.
- CharGenVerificationResponse.cs (new): promotes the shared 0xF643 parse
  out of CharacterRestore — full Code enum (Undef..AdminPrivilegeDenied=7,
  ACE's CharacterGenerationVerificationResponse) plus the conditional
  Ok-only identity payload (guid/String16L name/u32 secondsGreyedOut).
  CharacterRestore.Parse now delegates to it; CharacterRestore's public
  Parsed shape, Parse signature, and every existing test expectation are
  UNCHANGED.
- PacketWriter.WriteDouble: f64 little-endian helper for the shade fields.

WorldSession dispatch (Core.Net):
- Added an awaiting-request latch (None/Restore/Create), armed by
  SendRestoreCharacter/the new SendCharacterCreation immediately before
  each send (SendCharacterCreation builds the body first so a skill-count
  throw never arms the latch for a request that was never sent), cleared
  the instant a matching 0xF643 is dispatched (success OR parse failure —
  a malformed reply must never wedge the latch open) and on Dispose.
  0xF643 now routes to CharacterRestoreReceived or the new
  CharacterCreateResponseReceived (Action<CharGenVerificationResponse.Parsed>)
  by that latch; an unexpected 0xF643 with nothing outstanding logs once
  and is dropped, never misattributed. Fixed
  WorldSessionCharacterSelectionTests' restore-dispatch test, which
  previously fed a bare CharacterRestore response with no preceding
  SendRestoreCharacter — that shape is now the "no outstanding request"
  drop path by design.

Status events (Runtime + Launcher.Core, contract first):
- Amended docs/plans/2026-08-14-launcher-campaign.md §LA1's pinned status
  vocabulary to add characterCreated{guid,name} (Ok reply identity, named
  to mirror CharGenVerificationResponse's own fields and to read distinct
  from enteredWorld — retail logs a freshly created character straight in
  without a fresh characterList) and creationFailed{code,name} (raw Code
  value + its enum member name).
- SessionStatusWriter.CharacterCreated/CreationFailed implement that
  contract.
- Launcher.Core: CharacterCreatedStatusEvent/CreationFailedStatusEvent +
  StatusEventParser cases, in lockstep.

Tests: CharacterCreateTests (byte-exact layout incl. checksum term-set,
55-slot fixture, wrong-count throws), CharGenVerificationResponseTests
(every Code value), WorldSessionCharacterCreationTests (create-then-
response routes correctly, restore unaffected, no-outstanding drop,
second-response-after-consumed drop, Dispose clears the latch, a builder
throw never arms it), SessionStatusWriterTests + Launcher.Core
StatusEventParserTests/StatusFileTailerTests (pinned shape + tailer
round-trip) for the two new events.

Verified: dotnet build AcDream.slnx -c Release — 0 errors. Full solution
test run green (Core.Net.Tests 993/993, Runtime.Tests 1667/1667,
Launcher.Core.Tests 323/323, plus every other project in the solution).
WSL Ubuntu: Core.Net.Tests 993/993, Runtime.Tests 1667/1667.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/plans/2026-08-14-launcher-campaign.md

@@ -170,6 +170,7 @@ line, writer opens `FileShare.Read`, tailer opens
 `enteredWorld{characterId,characterName}`, `pluginLoaded{plugin}`,
 `pluginFailed{plugin,error}`,
 `loginCommandFailed{commandIndex,command,error}`,
+`characterCreated{guid,name}`, `creationFailed{code,name}`,
 `disconnected{reason}`,
 `exited{code,reason}` — every line carries `"v":1`, `"e"`, `"t"`
 (ISO-8601 UTC), `"sessionId"`. `secondsGreyedOut` is a uint on BOTH
@@ -177,6 +178,23 @@ sides. Unknown `e` values must parse to a typed Unknown event, never
 throw; a known `e` with a wrong payload shape should be distinguishable
 from an unknown `e` (LA3 review finding 12).
 
+**Campaign CC CC2 amendment (this section is the contract; the writer and
+tailer below implement it, in that order):** `characterCreated{guid,name}`
+fires on the Ok reply to a `CharacterCreate` (opcode `0xF656`) request —
+`guid`/`name` come straight off the shared `0xF643`
+`CharGenVerificationResponse` Ok identity payload
+(`AcDream.Core.Net.Messages.CharGenVerificationResponse`), deliberately
+named `guid`/`name` rather than `characterId`/`characterName` to mirror
+that payload's own field names and to read distinctly from
+`enteredWorld` — a freshly created character is logged straight in by
+retail without a fresh `characterList` (see that type's doc comment), so
+`characterCreated` can precede an `enteredWorld` for the same character
+rather than replacing it. `creationFailed{code,name}` fires on any non-Ok
+reply: `code` is the raw wire `CharGenVerificationResponse.Code` value,
+`name` is that code's enum member name (e.g. `"NameInUse"`) so a reader
+gets a stable readable reason without hard-coding the numeric mapping
+itself.
+
 `loginCommandFailed.commandIndex` is the zero-based index in the configured
 `loginCommands` array. `command` is the exact configured line and `error` is
 the isolated parser/router/handler failure. The event is observational: the
@@ -214,7 +232,8 @@ Three pieces, one slice, because they share the session-config/status seam:
    config; absent → permanent no-op sink). Versioned event
    vocabulary (`"v":1`): `started`, `connected`, `characterList`,
    `enteredWorld`, `pluginLoaded`/`pluginFailed`,
-   `loginCommandFailed`, `disconnected`, `exited`.
+   `loginCommandFailed`, `characterCreated`/`creationFailed` (Campaign CC
+   CC2), `disconnected`, `exited`.
    Recon: today's `HeadlessDiagnosticWriter` is a single shared-stdout JSONL
    sink with four kinds (lifecycle/failure/event/resources) and NO per-session
    file — the status writer is a second, separate sink, not a rework of the