Implement on-chain fuel and energy management for ships

[daatsuka]

This PR introduces src/energy_manager.rs, a new module that implements the full resource-consumption layer for ship energy in the Nebula Nomad contracts. The public surface is six functions — initialize_energy, consume_energy, recharge_energy, get_energy, set_base_recharge_rate, and apply_efficiency_bonus — all wired into NebulaNomadContract via src/lib.rs. Internally, balances are stored per-ship under an EnergyKey::EnergyBalance(ship_id) persistent key, and every mutation emits a Soroban event so horizon indexers can track consumption and recharge flows without polling. A private require_ship_exists helper gates every write path, ensuring that energy operations are only valid for minted ships already in ShipDataKey::Ship.

The recharge path was the trickiest part to get right: recharge_energy computes resource_amount * effective_rate / 100 in i128 space so intermediate products cannot overflow, then clamps the result back to u32 before calling saturating_add on the current balance. effective_rate itself is min(base_rate + per_ship_bonus, 100), which means blueprint upgrades stack with the global rate but never exceed 100 %. This design keeps the math deterministic and bounded while still giving game designers two independent knobs — a global dial (set_base_recharge_rate) and a per-ship dial (apply_efficiency_bonus) — to tune the economy. The small edits in governance.rs, indexer_callbacks.rs, and theme_customizer.rs are Soroban symbol_short! truncations required because the macro enforces a 9-character limit and a few existing literals exceeded it; these are compile-required, not behavioral changes.

A dedicated test file at tests/test_energy_manager.rs covers the full lifecycle: init-then-read, successful and insufficient consumption, zero-amount rejection, default and bonus-augmented recharge, overflow saturation at u32::MAX, a multi-step consume-recharge cycle, 25 consecutive micro-consumptions, and access on a non-existent ship. All ten tests (plus the existing suite) pass locally under cargo test with no panics or warnings, and the snapshot files checked in match the Soroban test-utils output exactly. I ran cargo build --target wasm32-unknown-unknown --release as well to confirm the WASM artifact compiles clean.

Closes #42

[parkerwinner]

@daatsuka fix conflict

[parkerwinner]

@daatsuka fix conflicts and cli falling checks