Build-time monitoring across lecture repos, with published benchmarks

[quantecon-services]

Why

Nothing records how long lecture builds take over time. Regressions surface only when someone happens to notice them. The measured baselines in #92 were collected by hand from individual runs. The idea was recorded in docs/FUTURE-DEVELOPMENT.md, which #178 removed (build monitoring, performance benchmarks).

Proposal

• Record timings for setup, build and the whole job, per repository and per runner type (container, standard runner, RunsOn AMI).
• Detect regressions through the job summaries.
• Publish comparisons: a periodic report or dashboard comparing runner types and tracking each repo over time.

Related

• Environment & config reporting: publish-time manifest + central data store #30 covers the publish-time environment manifest: what a build ran with. This issue covers how long it took. Both could share a data store.
• Optimize preview builds: phased plan for the fastest PR previews (tracking) #92 would use these numbers to confirm its expected savings.

Checklist

• Decide where timings are collected: job summaries, the Environment & config reporting: publish-time manifest + central data store #30 manifest, or a separate artifact
• Decide where they are stored and reported
• Pick the first repos to instrument