SBOM generation can be tricked due to inherent trust of installed packages file

**What happened**: I was running `syft` on a container image with openssl 3.5.0 but i deleted the file at `/lib/apk/db/installed`. This resulted in `openssl` 3.5.0 not to be found in the sbom.

**What you expected to happen**: I expected the openssl version to still be detected by checking the files at `/usr/lib` the same way syft detects versions for other programs.

**Steps to reproduce the issue**: build a container based on alpine 3.22, in the dockerfile `RUN rm /lib/apk/db/installed`. build the container. run syft on the container. The SBOM will be substantially smaller compared to an SBOM generated just from `alpine:3.22` without the db removed.

**Anything else we need to know?**: If `syft` inherently trusts the `lib/apk/db/installed` file to be correct, then a malicious user could simply remove or change the file to trick syft into thinking nothing is installed. `syft` should have some form of verification. From simplest to most complex: 1. the file exists, 2. the file is accurate, 3. `syft` doesn't trust the file at all and instead verifies the binaries themselves

**Environment**:
- Output of `syft version`: All versions
- OS (e.g: `cat /etc/os-release` or similar): all OS.

Reproduce the report by removing /lib/apk/db/installed from an Alpine 3.22 container and comparing syft's SBOM with an unmodified image. Read the package-detection path that uses that file and the binary inspection logic for files under /usr/lib; done means tampering or absence of the installed-packages file no longer hides installed software such as openssl.

Written by the indexing model from the issue text.