dmf-get: fallback to public manifest when module not found in provided manifest

[Copilot]

When a local/custom manifest is provided via -m, auto-discovered, or set via DMOD_MANIFEST, dmf-get now searches that manifest first and transparently falls back to the public registry manifest if the module isn't found. Both manifests remain alive throughout the session — the provided manifest is always the first choice for every module lookup, with the public manifest consulted only as a secondary source. A --no-fallback flag disables this behavior to enforce strict use of the provided manifest.

Changes

• GetContextForModule() helper — probes the primary (provided) manifest context for the requested module; if absent, lazily initialises and returns the public manifest fallback context without freeing the primary context
• Dual-manifest lifetime: both the provided manifest and the public fallback manifest are kept alive for the duration of the operation; the public manifest is parsed at most once per session
• Fallback applied in all three code paths:
  • Single module install
  • headers/docs resource extraction
  • Per-entry resolution when using a .dmd dependencies file (shared fallback context across all loop iterations)
• --no-fallback CLI flag — disables the fallback; module lookup stops at the provided manifest
• README updated with the new flag

Example

# Searches local.dmm first for each module; if absent, transparently retries against public registry
dmf-get -m local.dmm mymodule

# With a deps file: each module is tried against local.dmm first, then public registry
dmf-get -m local.dmm -d deps.dmd

# Strict mode — only local.dmm, no fallback
dmf-get -m local.dmm --no-fallback mymodule

Fallback is skipped when the provided manifest IS the public manifest (no redundant double-fetch).

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Dodać fallback w dmf-get do publicznego manifestu</issue_title>
<issue_description>Możemy stworzyć lokalny manifest, który będzie miał jakieś zależności, które musimy zainstalować, ale nie wszystkie. Celem tego zadania jest poprawienie logiki dmf-get tak, aby jeśli podamy lokalny manifest to żeby szukał modułu do instalacji najpierw z niego, a jeśli się nie uda to dopiero wtedy zrobił fallback do publicznego (domyślnego) manifestu (chyba, że użytkownik poda parametr cli który wyłącza fallback i wymusza używanie tylko podanego manifestu)</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Dodać fallback w dmf-get do publicznego manifestu #272

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[JohnAmadis]

@copilot chciałbym się upewnić, że to działa tak jak oczekuję - ten fallback nie ma być permanentny, tylko na potrzeby tych modułów, których brakuje. Czyli w sumie musimy mieć cały czas 2 przeparsowane manifesty i szukać w lokalnym modułu, a jeśli nie możemy go znaleźć to wtedy w tym publicznym. I potem następny moduł znowu najpierw w lokalnym

[Copilot]

@copilot chciałbym się upewnić, że to działa tak jak oczekuję - ten fallback nie ma być permanentny, tylko na potrzeby tych modułów, których brakuje. Czyli w sumie musimy m...

Dokładnie tak to teraz działa – obydwa manifesty są utrzymywane równocześnie. Refaktoryzacja w commicie 100d0a1 zastępuje poprzednie podejście (które niszczyło lokalny manifest) nową funkcją GetContextForModule():

• Lokalny/dostarczony manifest jest zawsze pierwszym wyborem dla każdego modułu.
• Publiczny manifest jest inicjalizowany leniwie przy pierwszym braku modułu i zachowywany na potrzeby kolejnych modułów (parsowany co najwyżej raz na sesję).
• Dla każdego kolejnego modułu sprawdzanie wraca do lokalnego manifestu.

W przypadku pliku .dmd z wieloma modułami: dep_fallback_ctx (publiczny manifest) jest współdzielony przez kolejne iteracje pętli, natomiast man_ctx (primary, per-wpis) jest tworzony i zwalniany osobno dla każdego wpisu.