Clarify engine service registry operations

[judus]

Context

Rocket uses a small service container/registry for engine parts and application services. The concept is useful, but the current API is too implicit:

service(name, null)      // get
service(name, undefined) // remove
service(name, instance)  // set

BaseContainer.add() also treats every function as a factory:

typeof item === 'function' // factory

That makes the engine bootstrapping harder to reason about, especially as more services and factories are registered in EngineInit.

Goal

Keep the service registry concept, but make the internal operations explicit and less surprising.

Proposed Scope

• Introduce explicit registry/container methods:
  • set(id, instance)
  • get(id)
  • remove(id)
  • factory(id, FactoryClass)
  • create(id, ...args)
  • has(id)
  • initAll(engine)
• Stop using null / undefined as internal get/remove signals.
• Stop treating every function passed to add() as a factory. Factory registration should be explicit.
• Update Engine.service() and Engine.plugin() to use the explicit methods internally.
• Update EngineInit to register services and factories explicitly.
• Keep EngineParts as the canonical service id list.
• Preserve the existing public behavior where practical, especially for current demo usage.

Non-Goals

• Do not redesign the full Rocket boot lifecycle in this ticket.
• Do not convert to TypeScript.
• Do not replace the service registry with a third-party dependency.
• Do not introduce automatic dependency injection.
• Do not change scenes, rendering, physics, or input behavior.

Acceptance Criteria

• Internal container operations are explicit and readable.
• Factories are registered explicitly rather than inferred from typeof item === 'function'.
• Existing demo behavior remains unchanged.
• rocket.service(...) can remain as public sugar if needed, but the implementation no longer depends on ambiguous null / undefined signaling internally.
• The service registry remains small and engine-oriented, not a general-purpose DI framework.