fix(errors): map application error codes to HTTP statuses

[hsinatfootprintai]

Closes #59 — "something like error with not found should be converted into http 404".

What was wrong

A "not found" left this service as HTTP 500. So did bad parameters, and every other application error. A client could not tell a missing document from a broken server.

The mapping was never missing. sderrors.Code has carried GRPCCode() for a long time (CodeNotFound → codes.NotFound, CodeBadParameters → codes.InvalidArgument, …), and grpc-gateway renders the HTTP status from the gRPC status. What was missing is GRPCStatus() on *sderrors.Error, which landed in a newer github.com/sdinsure/agent than this module pinned. Without it, every error left gRPC as codes.Unknown and the gateway rendered 500 — discarding a code the error was carrying the whole time:

[500] {"code":2, "message":"code(1), document nope not found in collection ..."}
       ^^^ HTTP         ^^^ Unknown   ^^^ CodeNotFound, right there

Consumers whose module graph already selected a newer sdinsure got correct statuses out of these same handlers — which is why grandturks saw a proper 501 from DeleteDocument while restcol standalone saw 500.

v0.0.0-20240507074650-281b67936555 -> v0.0.0-20260812141753-3e9fb7b72eaa

Measured, not assumed

case	before	after
missing document DELETE	500	404
missing document GET	500	404
unknown project DELETE	500	400

(GetCollection on a missing collection still answers 200 with an empty body — that is its own deliberate NotFound→empty-response behaviour, not this mapping.)

Migration

• runtime.ProjectInfor gained Visibility(). restcol has no per-project visibility — ModelProject carries an ID and a type, and authorization is AllowEveryOne — so it returns "", which the interface defines as unknown/unresolved and which sdinsure's own invalidProjectInfor returns. Inventing "PUBLIC" would tell a future authorization path that every restcol project is world-visible, on no evidence.
• logger.NewLogger gained a verbose bool. false preserves the old behaviour — the previous constructor logged at info and above; true would add debug.

A latent bug this surfaced

The bump carries gorm.io/driver/postgres 1.5.7 → 1.5.11 and pgx v5.5.5 → v5.9.2, and the newer pgx calls driver.Valuer on nil pointers where the old one short-circuited to NULL.

SwagValueValue.Value has had a pointer receiver since 073e3a3, so a nil *SwagValueValue satisfies driver.Valuer — and ModelFieldSchema.FieldExample is routinely nil (a field with no example):

unable to encode (*SwagValueValue)(nil) into text format for jsonb (OID 3802):
proto: google.protobuf.Value: none of the oneof fields is set

That failed every insert carrying a schema field without an example, taking out TestDocument and TestStorage. Value now returns NULL for a nil receiver, and Scan tolerates a NULL column instead of panicking on its type assertion.

Worth stating plainly: this was only visible because #134 made the postgres-backed tests run. On the old -short CI it would have merged green and broken writes in production. That is #134 earning its keep on its first outing.

Verification

Full suite against postgres:16-alpine:

• pkg/storage/{documents,collections,projects}, pkg/app, integrationtest — ok
• every remaining package — ok
• make gen-check — 0 (generated code still in sync)
• go vet ./... — clean

The integration assertions now check the HTTP status as well as the application code; the comment explaining why they couldn't is removed along with the reason for it.

Refs: #126, #134, FootprintAI/grandturks#936

🤖 Generated with Claude Code