Add a failing test for sibling copyright lookup

[hakandilek]

Debsbom._add_copyright() marks a source package as processed before checking whether the selected binary's copyright path resolves, so only one binary is ever tried per source. If that binary's /usr/share/doc/<package>/copyright does not resolve, the source loses its license information even when a sibling binary still provides one.

src/debsbom/generate/generate.py:311:

for bin_pkg in filter_binaries(packages.values()):
    src_hash = hash(bin_pkg.source_package())
    src_pkg = packages.get(src_hash)
    if not src_pkg or src_hash in src_processed:
        continue
    try:
        src_processed.add(src_hash)                    # marked before lookup
        src_pkg.copyright = cr_dir.copyright(bin_pkg)  # may raise FileNotFoundError
    except FileNotFoundError:
        logger.debug(f"no copyright information for {bin_pkg}")
        continue

filter_binaries() preserves insertion order, which is the dpkg status order, so which binary claims the source is deterministic but unrelated to whether its copyright path resolves.

Debian Policy §12.5 permits a binary's documentation directory to be a symbolic link to a same-source sibling it depends on, and debsbom resolves that correctly today because Path.is_file() follows symbolic links. The defect surfaces when such a link no longer resolves in the scanned root filesystem, for example after documentation pruning or an independent rootfs extraction.

Two SPDX fixtures cover this:

- tests/root/copyright-sibling: the first binary's doc link target was stripped; a sibling still ships the copyright file. This test currently fails (NOASSERTION instead of MIT) and demonstrates the defect.
- tests/root/copyright-linked-doc: a normal, resolvable --link-doc directory. This test passes and pins the Policy-compliant behaviour.

The fix is to mark the source as processed only after the lookup succeeds, letting the loop try the remaining binaries:

try:
    src_pkg.copyright = cr_dir.copyright(bin_pkg)
    src_processed.add(src_hash)
except FileNotFoundError:
    logger.debug(f"no copyright information for {bin_pkg}")
    continue

The fix commit is intentionally left out of this PR, due to the ongoing discussion.

[hakandilek]

@Urist-McGit I'm not really sure about this one yet. I just need to make a through analysis to figure out if there are valid examples of that. I'll create an issue once I've some data.

[Urist-McGit]

If a binary package does not distribute its copyright files this seems like a packaging bug. Does this actually occur?

[hakandilek]

If a binary package does not distribute its copyright files this seems like a packaging bug. Does this actually occur?

You're right and this doesn't occur in Debian, at least I could not identify it in Trixie, so I've dropped that overall claim and adapted the PR description to the actual latent defect.

I'm not sure if it should be addressed as bug, if then I'd file an issue as well.