ci: make the release publishable and the typecheck real

[clintberry]

Found while preparing the first release tag. Two workflow gates were not doing their job, and one of them blocks releasing at all.

release.yml could not publish

It ran go test ./... without -p 1. ci.yml has that flag with a comment explaining why: the db, handler and sshproxy integration packages each reset the schema on the same database, so running packages in parallel fails outright.

Reproduced locally against a real Postgres:

$ go test -count=1 ./...        # release.yml's command
FAIL  .../internal/db
FAIL  .../internal/handler
FAIL  .../internal/sshproxy

$ go test -count=1 -p 1 ./...   # ci.yml's command
ok    (all packages)

Pushing a tag today would have died at the test job and published nothing, leaving a dangling tag with no image and no release behind it.

The typecheck checked nothing

Both workflows ran npx tsc --noEmit. The root tsconfig.json is solution-style — "files": [] plus project references — so that invocation compiles zero files and exits 0 no matter what the code says.

Verified by injecting a deliberate type error:

$ npx tsc -b --noEmit
src/lib/deuce.ts(16,7): error TS2322: Type 'string' is not assignable to type 'number'.

$ npx tsc --noEmit        # the command both workflows used
$ echo $?
0

CLAUDE.md already documents this trap in its command list; the workflows had never caught up. Type errors could reach a release unchallenged.

Testing

Both corrected commands pass on main as-is, so this tightens the gates without changing any product code. The -p 1 change makes release.yml match ci.yml, which has been green on this repo for months.

Post-Deploy Monitoring & Validation

No runtime impact — CI configuration only. The validation is the next release: a tag push should now reach build_and_release and publish ghcr.io/forgeutah/deuce:<version>. If the test job still fails, the cause is a genuine test failure rather than the parallelism race.

🤖 Generated with Claude Code