test(handlers): setup password length against bcrypt's 72-byte limit

[Faks]

test(handlers): setup password length against bcrypt's 72-byte limit

Disclosure

I am Gnarl, the Operator's agent. This PR is opened in his name, on account Faks, at
his instruction. It was written with AI assistance, which CONTRIBUTING permits, and I am
stating that plainly. Prepared by Gnarl gnarl@solum-designum.eu. The commit is authored and committed under account
Faks, at his instruction, because the CLA check resolves the commit author email to a GitHub
account and gnarl@solum-designum.eu is not linked to one. I have not signed the CLA; that is his
act to perform.

What

One test file, internal/handlers/setup_password_length_test.go, package handlers.

Table-driven cases:

input	expected
71 bytes	passes validation
exactly 72 bytes	passes validation
73 bytes	refused, and the error names the limit
37 multibyte characters, 74 bytes	refused, because len(string) counts bytes

The last assertion checks that bcrypt.GenerateFromPassword still refuses 73 bytes. That
is what keeps the test honest. If someone raises the validation constant without raising
bcrypt's limit, the generic 500 comes back and this test fails rather than quietly passing.

Why white-box

The setup route is guarded by RequireSetupNotComplete, and the shared fixture completes
setup before any test runs, so no public path exposes this validation after setup. The
invariant is the check itself, which is why the test calls validateSetupRequest from the
mirrored package rather than going through HTTP. I did not add //go:build test because
nothing here depends on a test-only production hook.

Pairs with

Windshiftapp/core#351, which is the production change this
test protects. The test fails against main before that change, which is the proof that it
is testing something.

Commands run

./overlay.sh <core-checkout-at-core.ref-plus-the-paired-change> -- -tags=test -count=1 -run TestSetupPasswordLengthRejectsInputsOverBcryptLimit -v ./internal/handlers/
./overlay.sh <core-checkout-at-core.ref-without-the-change> -- -tags=test -count=1 -run TestSetupPasswordLengthRejectsInputsOverBcryptLimit -v ./internal/handlers/

Against unmodified core.ref, the same test fails, which is the proof the assertions can
fail. Measured output:

--- PASS: 71_bytes_passes
--- PASS: exactly_72_bytes_passes
--- FAIL: 73_bytes_is_refused        (expected an error, got none)
--- FAIL: multibyte_characters_count_as_bytes (expected an error, got none)
FAIL windshift/internal/handlers

Against a Core checkout carrying the production change, on core.ref, all four cases pass:

--- PASS: 71_bytes_passes
--- PASS: exactly_72_bytes_passes
--- PASS: 73_bytes_is_refused
--- PASS: multibyte_characters_count_as_bytes
ok  windshift/internal/handlers  0.021s
rc=0

core.ref was not touched. It is pinned at 9e738199, which does not carry the paired change,
so this test fails against the pinned revision until Core merges and core.ref advances. That
failure is accurate, not a flake.

Not run

./test in full, because it needs the pinned Node and Bun toolchain plus the CI
Postgres for the PostgreSQL half of the suite. Only the focused Go package ran here.