Spitball: drop gRPC, rewrite as plain net/http + huma JSON service

[SyniRon]

Investigation. Spitball the cost and shape of rewriting the API as a
plain net/http (Go 1.22 mux) + huma JSON service,
deleting proto/, buf*, grpc-gateway, the gRPC server, and the
gRPC listener port.

Motivation is not performance — it's deleting infrastructure nobody
appears to use. The gRPC port has no confirmed external consumers; known
clients are all HTTP-only.

Real work is translating the proto messages to plain Go structs and
replacing the auto-generated OpenAPI page (huma serves /docs from
struct tags). Public URLs stay identical, so no client changes are
required.

Prerequisite: the analytics task above. Verify zero gRPC traffic on
the gRPC port for at least a week before acting on this.

Likely promotes to its own project / planning issue when picked up.

[SyniRon]

This was generated by AI during triage.

Triage Notes

Scope is well-stated:

• Delete: proto/ (4 .proto + 4 generated .pb.go/.pb.gw.go), the three buf.* configs, the gRPC server package under servers/grpc/, and the :10000 listener wired in servers/server.go.
• Rewrite: handler set under a Go 1.22 net/http mux + huma, with proto messages translated to plain Go structs and the in-binary Swagger UI replaced by huma's /docs.
• Constraint: public URLs stay identical (per proto/milpacs.proto's google.api.http annotations) so no consumer changes are required. This is the right "Goodbye gRPC" framing — internal deletion, no external surface change.

Why this is blocked, not ready-for-agent:

The issue body's own prerequisite — "the analytics task above. Verify zero gRPC traffic on the gRPC port for at least a week before acting on this" — is gated on #92 producing data. Without that data the keep-or-drop call can't be made, and dispatching the rewrite work is premature.

This is also explicitly the alternative to #94 (replace deprecated gRPC dial APIs). The triage knot for the three together:

#92 (analytics) → produces traffic data
                ↘
                  decision: keep gRPC? → #94 (patch deprecated APIs)
                                    no → #95 (delete gRPC outright)

Unblocker: when #92's gRPC-port traffic numbers come in and the maintainer commits to "drop gRPC", this likely promotes to its own project/planning issue (per the body's own note) — the spitball gets a proper plan, gets split into landable PRs, and #94 gets closed as superseded.

Related: #92 (analytics, the prerequisite), #94 (the alternative path).