feat(scoreboard): add objectives, display slots and teams

[xRookieFight]

Description

The scoreboard was a per-player sidebar of fake-player lines and nothing else: no objective anyone else could see, no other display slot, and no concept of a team.

• Objectives, scores and teams live in one server-wide registry. Objectives are dummy ones whose scores the server sets, which is what every criterion other than the vanilla automatic ones amounts to.
• All three display slots work - sidebar, list and belowname - each with its own objective, so showing one does not disturb another. A score change redraws whatever slot is showing it.
• Teams carry a colour, prefix, suffix, friendly fire and name tag visibility. Bedrock has no team packet of its own, so a team does its work through the server: a member's name tag is decorated when it is sent, and two players on a team with friendly fire off cannot hurt each other.
• /scoreboard objectives|players|teams covers add, remove, list, setdisplay, set, add, reset, join, leave and option. Its messages are the vanilla ones.

Related issue

Part of #143

Name tag visibility is stored and settable but not yet enforced per viewer: hiding a name from other teams means sending different metadata to different players, which the broadcast path does not do today.

Checklist

• v -check . is clean
• v test server/player, server/cmd/default, and the session combat/scoreboard/broadcast/entity-view/login tests are green
• Follows the conventions in AGENTS.md (OOP, pub/capitalized exports, no import cycles, minimal comments)
• Cross-session gameplay state is only mutated on its owning world's actor thread (via world_call/wr.submit/WorldTx), never through a global Hub actor
• No unrelated changes bundled in

[nepinhum]

plus:

• scoreboard refresh itself is hilariously heavy (rebuilds every display slot by removing & recreating the objective and resending all scores to the entire server)

[nepinhum]

I'm not convinced Team belongs in the core scoreboard implementation. And this PR turns scoreboard state into a server wide gameplay framework: membership now affects combat, name tags, formatting and potentially per viewer visibility.

[nepinhum]

@bedrock-v/devs what do you think?

[nepinhum]

All entries are emitted as ScoreEntryChangeFakePlayer including list and belowname. Those slots need scores associated with actual player/entity identities and the protocol already has ScoreEntryChangePlayer / ScoreEntryChangeEntity for that. Won't belowname in particular fail to attach the score to the player model?

[nepinhum]

refresh_name_tags() broadcasts SetActorDataPacket through the whole Hub. Shouldn't actor metadata updates follow the same visibility/world scoped path as other entity updates? Sessions in unrelated worlds may not even have this actor spawned.