Add the bitbang-metrics-dump command and a build/test CI workflow - #2

Hi @kodareef5, many thanks for this -- the metrics feature was incorporated mostly because I wanted to get some simple metrics of direct-vs-relay numbers. I'll give this a good look when I get back from travel.

Thanks @kodareef5, and sorry this sat -- you were right about all of it, including the part
that was hardest to see from outside.

I verified the diagnosis from a clean checkout:

$ git archive main | tar -x -C /tmp/clean
$ cd /tmp/clean/bitbang-server && go build ./cmd/bitbang-metrics-dump
stat .../cmd/bitbang-metrics-dump: directory not found

git check-ignore -v confirms .gitignore:11 was matching the directory, not just the
built binary. So the documented production deploy has been broken for anyone but me, and I
would not have found it on this machine -- a clean checkout is the one thing I never do
here.

One thing you could not have known, and it explains why the docs described the command --I had already written it. :)
It has been sitting untracked in my working tree the whole time, which is exactly why
git add -A never complained and why the deploy kept working locally. You reimplemented a file
you had no way to see.

Having compared them, I am taking yours, and the deciding reason is not the one I expected:

Mine opens the database read-write. A mistyped path makes SQLite create an empty
database rather than fail. Yours uses mode=ro plus PRAGMA query_only, so it structurally
cannot create or modify anything. On a production metrics database that is the difference
that matters, and I would not have noticed it if you had not written the alternative next to
mine.

The tests are the other half. Mine has none -- it could not, being untracked -- and yours run
through the real recorder, so schema drift fails the build instead of surfacing as confusing
output months later.

Merging as-is

Not holding this for anything. It has waited long enough, and it fixes a deploy that is
broken on main right now.

One thing I would like to change afterward, and I would rather ask than quietly rewrite your
code: could -history emit oldest-first? Mine sorts ts DESC and then reverses, so the
output reads chronologically, which is what I want when eyeballing a trend on the box.
Newest-first is the more defensible default in the abstract; chronological is what I actually
use this for. Say the word and I will make the change myself post-merge, or push it here if
you would rather it be yours -- and if you have a reason for the other order, I would rather
hear it and keep newest-first.

Nothing else. The -db flag and the object/array shape are better than my
positional-argument-and-NDJSON version, and I will adjust my habits rather than ask you to
adjust the code.

On the CI

Good instinct pointing the cross-build step at the same commands upload_production uses --
that is the step that would have caught this, and it is the reason to have it rather than a
generic build.

One addition: check-latest: true alongside go-version-file. Without it the runner's
cached Go satisfies the constraint and never updates, so a standard-library advisory turns
the build red until someone bumps it by hand. That happened to me in bitbang-cli last week,
and worse, the release workflow had the same gap -- it would have shipped binaries built
against a standard library with four reachable advisories.

Also a heads-up for whenever you rebase: @Brumbelow's browser flow-control work in #4 adds
node --test web_test/, which will want a step in this workflow once both land. No action
needed now; just so the two of you are not surprised by each other.

Thanks again. A broken deploy path plus the reason it was invisible plus a test that keeps it
from recurring is a properly complete piece of work.