ext.properties "resource" not keeping input controls after restart

[Jerakin]

Describe the bug (REQUIRED) Properties defined in an ext.properties with type = resource will lose the controls after an editor restart.

To Reproduce (REQUIRED) Steps to reproduce the behavior:

1. Create an ext.properties.
2. Define a property.

[test]
my_property.type = resource

4. Open your game.project.
5. Insert a resource into the field.
6. Restart the editor.
7. Open your game.project, there are no longer any input controls for the property.

Expected behavior (REQUIRED) Input controls for properties should work after a restart

[AGulev]

• The resource control disappears after a restart because the extension setting gets downgraded to an “unknown string” meta
  setting during project load, and that placeholder then wins over the real ext.properties definition.

  - In editor/settings.clj load-settings-node (around load-settings-node, settings.clj:272), we build raw-meta-info from the
    built-in meta info plus any keys present in raw-settings by calling settings-core/add-meta-info-for-unknown-settings. At
    this point the extension meta info is not yet merged in.
  - After a restart, your game.project already contains test.my_property, so it is treated as “unknown” and added to raw-meta-
    info with type :string.
  - Later, the real meta info from ext.properties is merged in SettingsNode via settings-core/merge-meta-infos
    (settings_core.clj:245). That merge keeps the first definition of each path, so the earlier placeholder (type string)
    overrides the extension’s type = resource.
  - The form is therefore rendered as a plain string field on reload (no browse/open controls). On a fresh session before
    saving the value, the placeholder isn’t created, so the resource controls appear.

  To fix, the unknown-setting fallback needs to run after extension meta info is merged (or allow extension meta info to
  override unknown placeholders).

• Two viable fixes:

  - Move “unknown setting” augmentation after ext meta-info merge
      - What: In SettingsNode, delay add-meta-info-for-unknown-settings until after raw-meta-info has been merged with ext
        meta-info (meta-info output). That way, only truly unknown keys get placeholder meta; extension-defined settings keep
        their correct types.
      - Pros: Keeps merge semantics unchanged; no need to change merge-meta-infos; avoids double-processing of unknowns;
        cleanly separates “known via ext” from “unknown”.
      - Cons: Requires touching the load sequence in SettingsNode (ensuring all merge sites move the unknown-fill step),
        slightly more invasive to the load pipeline.
  - Let real meta override unknown placeholders
      - What: Change settings-core/merge-meta-infos so, when a path exists in both sides, the later meta wins (or specifically,
        unknown placeholders are discarded in favor of known meta). Then the ext meta, merged later, replaces the placeholder
        and the resource type survives reload.
      - Pros: Minimal change localized to merge semantics; lower risk of missing a call site; existing call order can stay.
      - Cons: Alters merge behavior globally: if two meta sources legitimately disagree, the last one now wins instead of
        first-wins-with-distinct-by. Could mask accidental duplicates; may need an explicit rule like “only override if the
        earlier one was unknown” to avoid regressions.

  Either approach works; the first is cleaner conceptually, the second is a smaller code change but tweaks merge rules.

[AGulev]

it's the same for the other types e.g. boolean