Look entity ids up instead of rebuilding them in editor scripts

[nickschuetz]

What

Every editor tool that takes an entity id resolves it in its editor-Python script through one shared resolver. That resolver tried azlmbr.entity.EntityId(int(id)) first and used it whenever IsValid() was true, otherwise scanning SearchBus for the entity.

The AiCompanion session found, and I confirmed live on 26.10.0, that EntityId(n) answers [4294967295] with IsValid() == False for every n, including a real id. So the resolver only ever worked through its fallback scan. It was correct by accident, and a constructed id that looked valid would have acted on the wrong entity.

Changes

• The resolver now always finds the entity's own id object by its text, and never constructs one.
• An unknown id raises inside the script. A small wrapper, added to any script that resolves ids, turns that into the error entity_not_found instead of a traceback, for all 16 tools that take an entity id.
• Script refusals from the AgentServer keep the gem's own code (secure_mode when editor Python is disabled, execution_failed, ...) instead of a hard-coded editor_error, so an agent can see why.
• CLAUDE.md records the convention: get an entity with _resolve_entity_id, never entity.EntityId(n).

Tests

• Surface: an unknown id gives entity_not_found. The harness's level now holds entities matching the sample ids, as a real level would, and the set_parent test reads back the parent it asked for.
• Unit: a secure_mode refusal keeps its code.
• Live (full suite 56 of 56, run together with the other pending fixes): every editor tool resolves through the new resolver, and get_transform on an unknown id returns {"status": "error", "code": "entity_not_found", "message": "No entity with id 123456789"}.