docs(governance): cut the dependency section to what it has to say

The second paragraph argued that an upstream maintained by an individual is
still an upstream. Nobody had disputed it, and a governance document that
defends an unraised objection invites the question instead of settling it.

What remains is the arrangement itself and where the components are listed.

Assisted-By: Claude
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>

GOVERNANCE.md

@@ -25,18 +25,12 @@ maintained under the `cozystack` namespace:
 
 Cozystack packages and ships software it does not govern. Such components remain
 under their upstream owner's namespace, are vendored by digest, and are neither
-released by this project nor mirrored under `ghcr.io/cozystack`. They are
-enumerated, with their licences, on the
-[Licenses](https://cozystack.io/docs/v1.6/operations/configuration/licenses/)
-page, which by construction lists upstreams only: what this project maintains is
-Apache-2.0 and is not listed there individually.
+released by this project nor mirrored under `ghcr.io/cozystack`.
 
-Some of those upstreams are maintained by individuals rather than organisations,
-and such an individual may also hold a role in this project. Neither fact makes
-the software a Cozystack component. The test is governance: a dependency keeps
-its own identity, licence and release process, and addresses a problem that
-exists outside Cozystack; a component is released under this project's
-governance and carries its licence.
+They are enumerated, with their licences, on the
+[Licenses](https://cozystack.io/docs/v1.6/operations/configuration/licenses/)
+page. That page lists upstreams only: what this project maintains is Apache-2.0
+and is not listed there individually.
 
 ## Community Roles