Feature/character lifecycle

[T4tsuk3i]

What this adds

Character creation and deletion from the character-select screen,
against 0.5.1's investment-store persistence.

Update after review

The review point was that the select-screen hold re-added a deleted client
hook and should be a server implementation instead. The hook
(character_select_hold.cpp, its lifecycle registration, declarations and
project entry) is removed, and the hold now comes from what the server does.

The client was leaving the select screen because the server invented a pick
the player never made. create_character marked the new character selected,
and delete_character handed the selection to a survivor. Moving the account
onto a character is what a real pick (opcodes 504/505) does, so the step had
nothing left to wait for.

• Create onto a roster that already has characters, and delete, change the
  roster without selecting anything. Only the player picks.
• The opcode 501/502 handlers no longer stage a SelectCharacter Family-4
  move for that invented pick. They arm the account resync they already arm
  and name the revision it publishes (family4Version + 1), the same "name
  the following resync" contract the claim path uses, so the reply names a
  publication that actually arrives.
• With nothing selected now a real, expected state, the Family-0 appearance
  and Family-3 roster resync lanes return without publishing instead of
  failing. The Family-4 account frame still goes out, so the roster count
  moves immediately.

The bugs, and how each was found

1. Delete disconnected the client with a Bungie network error.
opcode 502 answered with a bare echo, not the status-pair shape
middleware::web_service::encode_response produces everywhere else.
opcode 501 answered with the right shape but hardcoded
status.value = kNoFamily4Publication unconditionally, correct for its
original "echo the already-selected character" use, wrong once the
request actually mutates the roster. The client blocks after these
requests waiting for a Family-4 publish at the version the response
names; either bug leaves it waiting on one that never comes, and it
times out into a disconnect.

Fixed by moving the handling into bap_service_body.cpp next to the
existing opcode 505 (change-character) block, and encoding a real
status pair. The log shows a clean ev=ws502 stage=delete result=ok /
ev=ws501 stage=create result=ok pair for every request.

2. Created character never actually appeared. With (1) fixed, create
returned success but the character never showed up client-side. The log
showed a tight, permanent retry loop instead:

server level=warn ev=family4 stage=prepare result=fail step=character_encode
server level=warn ev=queuez stage=peer_resync result=fail reason=family4

repeating every ~50ms, forever. Tracing the failing character::encode
call into equipment_summary_builder.cpp found the actual guard:
evaluation.divisor <= 0 unconditionally rejects the encode. divisor
is the count of the 8 weapon/armor slots with something equipped; a
created character starts with none, so it can never pass this check and
can never be published.

Fixed by seeding all 17 native equipment slots on creation, sourced from
this build's own authored default character's item hashes
(resources/database/investment_defaults.sql), each given a freshly
allocated instance SOID via the same collision-avoidance scan
ensure_character_subclasses already uses.

3. Every created character had the same gear regardless of class.
The fix above initially reused one fixed 17-item set for every class. A
Hunter came out wearing a Titan subclass and Titan armor. Fixed by
splitting the loadout into 10 slots that are class-agnostic (weapons and
cosmetic/utility slots) and 7 that are not (armor, class item, subclass,
and the emblem variant), chosen per class from known item definition
hashes.

4. Create/delete loaded straight into orbit instead of refreshing the
roster. Removing the Family-4 publish staging entirely had no effect on
this, which showed the response was not the cause. The cause was the
server moving the selection on create and delete, as described in the
update above. A deleted character that logged ev=ws502 stage=delete result=ok was followed within a second by successfully changed world to: orbit_d2 and falling back to a new character.

Existing bug in Sunrise since 0.3

The head doesn't render on a created character, independent of the
show/hide-helmet setting. Race/gender/class all display correctly on the
character-select screen, so identity data is going through; this looks like
a narrower rendering issue, not a data problem. Not root-caused yet.

Verification

Built via clang-cl/lld-link cross-compiling to x86_64-pc-windows-msvc, then
deployed and tested in-game. No client hook is installed in the tested
build.

• With characters on the roster, the select screen stays up at boot until
  the player acts (about 54 s in one run, no hook, no setup:orbit).
• Deleting a character leaves the select screen up and the roster one
  shorter, with ev=ws502 stage=delete result=ok and no orbit transition.
• Creating a character from the select screen leaves it up, with
  ev=ws501 stage=create result=ok.

Not covered by this build's test runs: picking a character after a
create or delete, and a relaunch with several characters.

The game does not offer deleting the last remaining character, so a
delete-everything path is not exercised through the UI.

[stanuwu]

this adds back a deleted client hook, should use a proper server implementation instead

[T4tsuk3i]

ok will do working on it might take a bit of time

[T4tsuk3i]

@stanuwu thanks for the review. The client hook is removed and the select-screen hold is now done on the server: the server no longer selects a character on create or delete, so the step has no pick to leave on. I rewrote the description above to match. Could you take another look?