Replace magic application service key with explicit application API

[judus]

Context

Rocket currently registers the application through the generic service container:

rocket.service('application', new Application());

That works, but 'application' is a magic string. Users have to know the key exists, and the API does not tell them what lifecycle methods an application may implement.

This is especially awkward because the application object is a core bootstrapping concept, not just an arbitrary service.

Goal

Make application registration explicit and discoverable without redesigning the engine lifecycle or moving to TypeScript yet.

Proposed Scope

• Add EngineParts.APPLICATION = 'application'.
• Replace internal raw 'application' lookups with EngineParts.APPLICATION.
• Add a public rocket.application(app = null) convenience method:

rocket.application(new Application());
const app = rocket.application();

• Optionally add engine.application(app = null) if that keeps delegation consistent.
• Update the demo bootstrap from:

rocket.service('application', new Application());

to:

rocket.application(new Application());

• Make BaseApplication document the intended optional lifecycle hooks:
  • init(engine)
  • onLoad() or load() depending on the existing convention we keep
  • update(deltaTime, tickCount, totalTime)
  • render(alpha, tickCount, totalTime)
  • stop() / destroy() only if already meaningful enough
• Optionally update the demo Application to extend BaseApplication instead of the generic EngineBase.

Non-Goals

• Do not redesign the full boot lifecycle in this ticket.
• Do not convert the engine to TypeScript in this ticket.
• Do not replace the service container.
• Do not change scene, renderer, physics, or input behavior.

Acceptance Criteria

• User-facing examples no longer require rocket.service('application', ...).
• Internal code no longer relies on raw 'application' string literals for the core application service.
• BaseApplication clearly shows which hooks an application can implement.
• Existing demo behavior remains unchanged.
• No unrelated cleanup or architecture changes are included.