feat(http): make tenant-id reject status configurable (#29)

[lu1tr0n]

Hi @mathias82 — thanks again for the clear framing on #29. This implements it.

Closes #29.

What changed

• New quarkus.multi-tenant.http.tenant-id.reject-status (default 400) on the tenant-id config group.
• TenantFilter uses it only for the syntactic tenant-id validation failure (the Resolved-but-invalid branch). An authentication-related TenantResolution.Rejected (e.g. an untrusted bearer token) is untouched and still returns 401.
• Default is 400 because a malformed tenant id is bad request input, not an authentication failure; setting reject-status=401 restores the previous single-status behaviour.

One nuance worth a look during review: TenantIdValidator runs on every Resolved outcome, so a valid JWT whose tenant claim value breaks the length/charset policy is treated as a syntactic failure (→ reject-status), while a bad token stays Rejected (→ 401). That keeps "bad value" and "bad credential" cleanly separated, which I think matches the intent — happy to guard it differently if you'd prefer an authenticated-but-malformed claim to stay 401.

Verification

• HTTP module suite green (44 tests). New TenantIdRejectStatusTest covers the custom status plus "auth rejection stays 401"; TenantIdValidationTest updated to the new 400 default; TenantFilterDispatchTest confirms the Rejected path is unaffected.
• Also exercised end-to-end against a small external consumer app over live HTTP across four configs (default → 400, reject-status=422 → 422, reject-status=401 → back-compat, validation-enabled=false → off), with the auth rejection staying 401 throughout.

Docs and CHANGELOG are updated with the property and the auth-vs-syntactic distinction.

On the default: I went with 400 as proposed in the issue, but it's a one-liner to flip if you'd rather ship 401 as the default and let adopters opt into 400 — let me know and I'll adjust. Thanks!