Fix false "Bad custom block" errors for CraftEngine blocks on startup

[Copilot]

AOneBlock's onEnable runs before CraftEngine populates its block registry, so CraftEngineHook.exists(id) returns false for every valid type: craftengine block — flooding the log with ERROR: Bad custom block on every phase that uses CraftEngine blocks. The blocks work fine because CraftEngineListener triggers a full phase reload on CraftEngineReloadEvent, at which point the registry is ready.

Changes

• CraftEngineCustomBlock.fromMap() — decoupled from fromId(). When a YAML entry explicitly declares type: craftengine, the block type is unambiguous; the object is now created directly from the id field without consulting the registry:

  // Before: delegated to fromId() → CraftEngineHook.exists() → false at startup → Bad custom block
  public static Optional<CraftEngineCustomBlock> fromMap(Map<?, ?> map) {
      return Optional.ofNullable(Objects.toString(map.get("id"), null))
              .flatMap(CraftEngineCustomBlock::fromId);
  }
  
  // After: create directly; runtime execute() handles invalid IDs gracefully
  public static Optional<CraftEngineCustomBlock> fromMap(Map<?, ?> map) {
      String id = Objects.toString(map.get("id"), null);
      if (id == null) return Optional.empty();
      return Optional.of(new CraftEngineCustomBlock(id));
  }

• fromId() retains the exists() check — it doubles as the short-form creator and must not greedily match vanilla material names.

• Added fromMapReturnsPresentWhenIdProvided test to cover the previously broken path.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud