Bug: derive selectable semantic surfaces from the actual project instead of hard-coded IDs #3

Related to #1.

Problem

defaultSelectableSurfaces(ProjectModel project) currently ignores the supplied project and always returns demo IDs such as:

• main_enclosure.top_lid.outer
• main_enclosure.front_wall.outer
• main_enclosure.bottom_inside

That can report surfaces which do not exist for the current body/lid configuration and assumes the enclosure ID is always main_enclosure.

This becomes especially problematic for MCP/CLI introspection (list_surfaces), because an agent must be able to trust that returned semantic targets really exist.

Goal

Make selectable-surface discovery deterministic and derived from current semantic project state (and backend capability where necessary).

Requirements

• Derive surface IDs from actual enclosure/body IDs.
• Respect lid configuration: do not expose a top-lid surface when the project has no top lid.
• Support multiple bodies/enclosures without collisions.
• Keep user-facing labels separate from stable semantic IDs.
• Do not expose raw OCCT face/topology IDs.
• Keep the result stable enough for saved semantic references and MCP tools.
• If a requested surface type is not supported by the active geometry backend, report that explicitly rather than inventing a target.

Tests

Add cases for at least:

• enclosure with a non-default ID
• enclosure with top screw lid
• enclosure with no lid
• multiple bodies
• invalid/stale semantic surface reference

Done criteria

getSelectableSurfaces(project) never returns a hard-coded demo surface that is absent from the supplied project, and consumers can use the returned semantic IDs as authoritative edit targets.