docs: publish the security, contribution and conduct policies

[BryanFRD]

Three files the repository never had, and the reason Scorecard reports no effort toward an OpenSSF Best Practices badge. Two of them are also required for the badge's passing level on their own.

SECURITY.md. Private advisories first, with the org address as the fallback, and the response times the criterion asks for: acknowledged in 3 working days, assessed in 10, fixed before disclosure. What is in scope is written as the failures this server exists to prevent, so a reporter can tell whether they have one: an object served to a caller the forge would refuse, an escape from the storage root, bytes accepted that do not hash to their digest, a pre-signed URL granting more than the batch was about to, two callers holding one lock, a credential in a log. What is out of scope is written just as plainly, starting with LFSX_AUTH=disabled, which accepts every request by design.

CONTRIBUTING.md. What a change has to carry before it can merge: the test that fails without it, a green gate, documentation in the same change, a conventional commit whose type drives the version bump. It also says what happens after a pull request, including that the review will disagree with the work, which is better learned from a file than from a surprise. The local recipes are there too, including running the bucket suite against MinIO, since those tests skip rather than fail when the endpoint is unset.

CODE_OF_CONDUCT.md. Adapted from the Contributor Covenant rather than pasted, because a policy nobody reads is a policy nobody follows. Not required for the badge's passing level; required for silver.

The README gains a Contributing section pointing at the first two.

One correction made while writing: my first draft invented security@ferrlabs.com and conduct@ferrlabs.com. Neither exists. Both now use contact@ferrlabs.com with a subject prefix, which is what the organisation policy actually names. A contact address that bounces is worse than none, since it fails silently at the moment somebody is trying to warn you.

The badge itself is a self-certification at bestpractices.dev and needs a human with a GitHub account. These files are what most of its criteria ask to see.

[ferrfleet]

Checked every path and command these files reference against the head commit: docs/configuration.md, docs/releases.md, docs/reverse-proxy.md, LICENSE, ci/e2e.sh all exist, the lfsx-server binary name matches the package, and "MinIO and Garage in CI" matches the two bucket jobs in ci.yml. One command does not work as written (bucket creation is missing), plus two nits.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}

[BryanFRD]

All three taken.

The bucket recipe was indeed broken as written: nothing in the server calls CreateBucket, and an_instance_that_cannot_reach_its_bucket_is_not_ready depends on a missing bucket staying missing, so the suite would have failed rather than run. The block now mirrors the MinIO job in ci.yml (mc alias set then mc mb --ignore-existing local/lfsx-test) and says why the bucket has to pre-exist, plus where the name comes from.

The duplicated build block is gone: "Building it" is now a pointer at docs/development.md and keeps only the bucket recipe, which that page does not cover. And line 30 no longer contradicts line 28, it reads "A pull request for anything larger references its issue".

5b61d8b.

[ferrfleet]

All three findings are fixed in 5b61d8b. The bucket recipe now creates lfsx-test before running the suite, matching the MinIO job in ci.yml, and "Building it" points at docs/development.md instead of restating it. Nothing new in the changed lines.