fix(installer): don't fail install when a dependency has no boss.json

[Spelt]

verifyDependencyCompatibility loads the dependency's boss.json to check engine/platform constraints, but returned an error when the file does not exist. Most Delphi libraries (Kastri, Alcinoe, ...) ship without a boss.json, so any install of such a dependency failed with:

failed to load package from ...\boss.json: The system cannot find
the file specified.

Treat a missing boss.json as "no engine constraints declared" and skip the compatibility check; other load errors (e.g. malformed JSON) still fail the install.

[isaquepinheiro]

Tested this here and it is correct — measured, not just read. Details below in case they help move it along.

Reproduced first. A user on v3.0.17 hit exactly this on a fresh clone: 2 of 12 dependencies died, one of them github.com/academiadocodigo/localcache4d, which ships no boss.json on any tag (1.0.1–1.0.4) or on its default branch. Same message as in your description.

Then measured. Two binaries from the same tree (v3.0.17, 1ea375d), differing only by this patch, run against a boss.json whose single dependency is that library:

Binary	Result	Exit
v3.0.17	⛓️‍💥 Failed — failed to load package from ...\boss.json: The system cannot find the file specified → ❌ Installation failed	1
v3.0.17 + this PR	📦 Installed → ✅ Installation completed successfully!	0

The baseline reproduces the reported output byte for byte, and the patched build then prints ⏩ github_com_academiadocodigo_localcache4d Skipped — no boss.json in the build stage — the message that already existed, which is the clearest sign the rest of the pipeline always expected a manifest-less dependency to be normal.

The errors.Is chain holds, for anyone reviewing: os.ReadFile returns *fs.PathError (fs.go:31), passed through unwrapped by FilePackageRepository.Load (package_repository.go:29-32), then wrapped with %w in PackageService.Load (package_service.go:51). Both wraps preserve the chain, so the match works. errors and os were already imported in core.go, so no new import.

Origin, for the record: cef145b flipped return "", nil to return "", err in this function as part of a lint sweep — most likely to satisfy nilerr. Affects every tag from v3.0.13 through v3.0.17 (git tag --contains cef145b). Not a policy change, and nothing in the suite objected at the time.

Suite: with this patch applied, go test ./... gives 29 packages ok, 0 failures, go vet clean.

I opened #286 with three regression tests for this — tests only, no production code, so it does not compete with this PR. It covers the missing manifest, plus a malformed boss.json still being reported (so the fix stays narrow and the original nilerr intent survives) and the strict-mode platform check still refusing a mismatch. It is a draft because WithoutBossJSON fails on main until this merges. Merge this one first and #286 goes green — or fold those tests straight into this PR if that is easier, whichever gets it released sooner.

One last thing worth flagging: v3.0.17 was published 2026-08-22, so even after this merges, anyone hitting the bug stays broken until there is a new tag.