Fix SBOM team permission handling

[ryanlink]

Overview

• Include team information in SBOM analyze metadata
• Add test coverage for team-scoped permissions
• Update documentation to clarify team permission behavior

This change allows users with team-scoped permissions to use fossa sbom analyze --team when they are members of the specified team, matching the behavior of fossa analyze --team.

Currently, users with None permissions but Team Admin status are unable to upload SBOM projects to their team.

Acceptance criteria

• Users without org-level permissions are able to analyze an SBOM using fossa sbom analyze --team [team-name] for any team of which they are a member.

Testing plan

• [Zach] I built this example locally and tested it. It succeeds.

I spent time investigating how to write tests for this example and unfortunately found that while we do test preflight checks, we aren't able to test at this level of integration. For example, we have tests for AnalyzeChecks which SBOM analysis uses, however, the issue was that the team argument was omitted. AnalyzeChecks is properly tested, however ,I believe that writing a test to prevent this scenario would require a higher-level integration test over the sbom analyze workflow. I am open to ideas here!

Risks

Very low risk. This only impacts pre-flight checks. The worst thing that can happen is that people have to wait ~20 seconds to see an API call fail.

References

ANE-2241: Implement SBOM team analyze preflight check errors

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.