Rename scrap-drop entity to "debris" in code and config

Implements the requirements rename in the codebase. The salvageable object
dropped by destroyed ships and defence stations is now the "debris" entity;
the scrap resource it yields (cargo, delivery, smelting, threat,
scrap_drop_formula, scrap_per_threat) is unchanged.

Entity renames: ScrapDataComponent->DebrisComponent, ScrapSystem->DebrisSystem,
ScrapInfo->DebrisInfo, ScrapSelectionChangedEvent->DebrisSelectionChangedEvent
(member scrap->debris), spawnScrap->spawnDebris, getScraps->getDebrisSystem,
getAllScrapInfo->getAllDebrisInfo, scrapAtWorldPos/scrapInBox->debris*,
SalvageScrapBehavior::scrapTarget->debrisTarget, PendingCollection::scrap->debris,
ScrapTest.cpp->DebrisTest.cpp. Config key scrap_despawn_seconds->
debris_despawn_seconds (WorldConfig.scrapDespawnSeconds->debrisDespawnSeconds).
The salvage/deliver behavior classes keep their names (they act on the scrap
resource).

Also implements the new REQ-UI-DEBRIS-PANEL behavior in SelectedBuildingPanel:
a single selected piece of debris shows a "Debris" heading plus a "Scrap" stat
row; a multi/mixed field selection appends "Debris x N" and "Scrap x N" lines.

Updates the four renamed REQ-ID references in comments/docs, plus architecture.md
and derived.md. All 449 test cases pass; app, tests, and balancing targets build.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y7N59FsLA5e2kuVdqe4Uhc

docs/architecture.md

@@ -25,7 +25,7 @@ The simulation advances in discrete ticks. All game quantities — production ti
 
 - Tick rate: fixed at 30 Hz; `tickDurationMs = 1000 / 30 ≈ 33.33`.
 - Ticks are driven by an accumulator that is independent of the render rate. Each render frame, the driver adds `elapsedWallMs × gameSpeedMultiplier` to an accumulator and flushes one `tick()` per `tickDurationMs` of accumulated time (so multiple sim ticks may run between frames at high speeds, or a frame may run no ticks at low speeds). `gameSpeedMultiplier` ∈ {0, 0.5, 1, 2, 4} per REQ-UI-SPEED; 0× freezes the accumulator (pause). The concrete driver lives in the Rendering section.
-- Config-level durations given in seconds (recipe durations, wave gap ranges, scrap despawn, etc.) are converted to ticks at config-load time.
+- Config-level durations given in seconds (recipe durations, wave gap ranges, debris despawn, etc.) are converted to ticks at config-load time.
 
 Consequences: determinism, replayability, and the time-scale feature fall out for free. The simulation advances the same number of ticks over the same amount of game-time regardless of whether the game renders at 60 FPS, 30 FPS, or a stuttery mix.
 
@@ -44,7 +44,7 @@ See REQ-GW-COORDS for the authoritative tile-coordinate convention. This section
 
 - Tile coordinates are `QPoint(x, y)`. Origin `(0, 0)` is the first space tile (just right of the asteroid's right edge at game start). X grows right; Y grows down.
 - Asteroid tiles have `x < 0`. Asteroid left-expansions add tiles at increasingly negative X; the origin never shifts, so existing tile coordinates remain stable across expansions.
-- Continuous world positions (ship centers, scrap drops, projectiles) use `QVector2D` in tile units — one tile = 1.0 world unit. A ship center at `QVector2D(-3.5, 4.0)` sits at the center of the tile 3.5 tiles left of the asteroid's right edge and 4 tiles down from the top.
+- Continuous world positions (ship centers, debris, projectiles) use `QVector2D` in tile units — one tile = 1.0 world unit. A ship center at `QVector2D(-3.5, 4.0)` sits at the center of the tile 3.5 tiles left of the asteroid's right edge and 4 tiles down from the top.
 - Rendering multiplies world units by the tile size in pixels (20) at draw time.
 - Ship position always refers to the ship's center — this is the point used for sensor, attack-range, and hit-detection checks.
 
@@ -52,7 +52,7 @@ See REQ-GW-COORDS for the authoritative tile-coordinate convention. This section
 
 Simulation types shared across subsystems:
 
-- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, scrap drops, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `AttackBehavior.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
+- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, debris, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `AttackBehavior.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
 - `Rotation` — enum `{ North, East, South, West }`. The rotation applied to a building's surface_mask when placed.
 - `BuildingType` — enum covering every building type in requirements.md (Miner, Smelter, Assembler, ReprocessingPlant, Shipyard, SalvageBay, Belt, Splitter, Hq, PlayerDefenceStation, EnemyDefenceStation). `Belt` and `Splitter` share the enum for cost, construction, placement, and `visuals.toml` lookup, but their runtime data lives inside the belt subsystem rather than in `Building` instances (see Belt Subsystem).
 - `ItemType` — tagged id of every transportable material (ores, ingots, intermediates, building_blocks, scrap).
@@ -115,9 +115,9 @@ Within a single simulation tick, subsystems run in this fixed order. The order i
 6. **Belt tick** — advance items along belt tiles; apply splitter routing (REQ-BLD-SPLITTER).
 7. **Ship behavior systems** — clear `MovementIntent` on each ship, then the `AiSystem` runs three batched phases: every behavior **evaluator** scores its behavior and sets its target data; a **selection** pass records the highest-scoring behavior per ship in `SelectedBehaviorComponent`; each behavior **executor** runs for the winner, writing `MovementIntent` and preferred module targets. The module systems then perform world mutation: `SalvagerSystem` (scrap collection/delivery) and `RepairSystem` (healing). See Movement Arbitration.
 8. **Combat resolution** — ships and defence stations validate/acquire targets, fire, apply damage; queue deaths. Each fire appends a `BeamFiredEvent` to the sim's beam-fired-event queue (REQ-SHP-FIRING-BEAM). The repair and salvage module systems (tick step 7d) append their own `BeamFiredEvent`s to the same queue when they start a cycle.
-9. **Deaths & loot** — process queued deaths: drop scrap (REQ-RES-SCRAP-DROP); if a full enemy-defence-station set was destroyed this tick, generate up to 3 schematic choice options (REQ-DEF-SCHEMATIC-DROP) stored as pending state for the UI to present; remove entities.
+9. **Deaths & loot** — process queued deaths: drop debris (REQ-RES-DEBRIS-DROP); if a full enemy-defence-station set was destroyed this tick, generate up to 3 schematic choice options (REQ-DEF-SCHEMATIC-DROP) stored as pending state for the UI to present; remove entities.
 10. **`tickMovement`** — advance ship positions based on final `MovementIntent`.
-11. **Scrap despawn** — decrement scrap timers; remove expired scrap (REQ-RES-SCRAP-DROP).
+11. **Debris despawn** — decrement debris timers; remove expired debris (REQ-RES-DEBRIS-DROP).
 
 ## CMake Target Layout
 
@@ -193,20 +193,21 @@ struct Building {
 - Belts and splitters are separate types owned by the belt subsystem, not general `Building` instances.
 - No ECS for buildings. A miner is never also an assembler; there is no composition benefit to decomposing buildings into components.
 
-## Scrap
+## Debris
 
-Scrap is the only non-ship, non-building entity in the simulation:
+Debris — the salvageable object dropped by destroyed ships and defence stations — is the
+only non-ship, non-building entity in the simulation. Each piece carries a scrap amount:
 
 ```cpp
-struct Scrap {
+struct Debris {
     EntityId id;
     QVector2D position;     // world units, tile-fractional; ship-center convention
-    int amount;
-    Tick despawnAt;         // absolute tick at which the scrap is removed
+    int amount;             // scrap the piece still holds
+    Tick despawnAt;         // absolute tick at which the debris is removed
 };
 ```
 
-Created in tick step 9 (Deaths & loot) per REQ-RES-SCRAP-DROP, consumed by salvage ships in tick step 7 (ScrapCollector), and removed in tick step 11 when the current tick reaches `despawnAt`.
+Created in tick step 9 (Deaths & loot) per REQ-RES-DEBRIS-DROP, drained one scrap per cycle by salvage ships in tick step 7 (SalvagerSystem), and removed in tick step 11 when the current tick reaches `despawnAt`.
 
 ## Ships
 
@@ -234,7 +235,7 @@ struct RetreatBehavior      { float retreatHpFraction; QVector2D retreatPoint;
 struct AttackBehavior       { std::optional<EntityId> currentTarget; float score; };
 struct RepairBehavior       { std::optional<EntityId> currentTarget;
                               float maxRepairRange_tiles; float score; };
-struct SalvageScrapBehavior { std::optional<QVector2D> scrapTarget;
+struct SalvageScrapBehavior { std::optional<QVector2D> debrisTarget;
                               float maxCollectionRange_tiles; float score; };
 struct DeliverScrapBehavior { BuildingId deliveryBay; float score; };
 struct SelectedBehaviorComponent { BehaviorKind winner; float bestScore; };     // selection result