Harden the free Render runtime

[raghubetina]

Summary

This keeps the deliberately small Render Free runtime profile, while closing several gaps found in a current audit:

• treat SOLID_QUEUE_IN_PUMA as enabled only for the literal value "true" (so "false" no longer starts queue actors)
• defer ApplicationJob enqueues until the surrounding transaction commits, avoiding accidental dependence on same-database transactional enqueue behavior
• restore the standard /up liveness route and use it from both Docker and Render health checks
• remove MALLOC_ARENA_MAX, which tunes glibc malloc and is inert because this image preloads jemalloc and already configures jemalloc through MALLOC_CONF
• make the Solid Cache budget configurable and lower its default from 256 MB to 64 MB, leaving most of Supabase Free's 500 MB database quota for application data, Queue, and Cable
• remove the inherited encrypted credentials blob, for which template consumers do not have a master key, and document SECRET_KEY_BASE in the Docker run example
• add focused request and job-configuration specs

This addresses the runtime portions of #26. It intentionally does not attempt that issue's broader Codespaces/tooling work.

Why

The current free-tier process topology came from production incidents and should remain intact:

• Run Puma in single mode on Render free tier #22 and aplace#54 established that WEB_CONCURRENCY=1 creates Puma master + worker overhead and OOM-loops a 512 MB service. Render also now supplies WEB_CONCURRENCY=1 by default for newer services unless overridden (Render default environment variables).
• Run Solid Queue in async mode on Render free tier #23 and aplace#58 established that Solid Queue fork mode reached about 530 MB while async mode plateaued near 300 MB.
• Use a single database for primary, cache, queue, cable #24 intentionally put primary, Solid Cache, Solid Queue, and Solid Cable in one database. Solid Queue's transactional-integrity guidance recommends enqueue_after_transaction_commit when using that topology without coupling application behavior to the queue backend.
• Co-locate web service region with DB + Supabase pooler hardening #27 measured cross-region database latency and established the Ohio/Supabase co-location rule. This PR leaves the provider-specific region and pooler settings unchanged.

The app already silenced /up in production but did not define the route, and neither its image nor Blueprint checked it. Render recommends a health endpoint that returns 2xx/3xx only when the service is healthy (health-check documentation); /up is intentionally liveness-only here.

The image preloads jemalloc and already sets MALLOC_CONF. jemalloc documents MALLOC_CONF as its runtime configuration mechanism (jemalloc manual); MALLOC_ARENA_MAX is a glibc allocator tunable and therefore conveyed false confidence in this image.

Supabase Free currently caps database size at 500 MB (official pricing). A 256 MB cache ceiling reserved more than half of that shared database before application, Queue, and Cable data. SOLID_CACHE_MAX_SIZE_MB keeps the smaller default adjustable for apps that outgrow the free profile.

Validation

• bundle exec rspec — 3 examples, 0 failures
• bin/rubocop app/jobs/application_job.rb config/puma.rb config/routes.rb spec/jobs/application_job_spec.rb spec/requests/health_spec.rb — 5 files, no offenses
• docker build -t rails-8-template-upstream:pr . — production image builds without a master key
• fresh PostgreSQL production boot with WEB_CONCURRENCY=0 and SOLID_QUEUE_IN_PUMA=true — Puma single mode and Solid Queue async supervisor both start
• Docker health status reaches healthy; /up returns 200 through Thruster
• production boot with SOLID_QUEUE_IN_PUMA=false starts no Solid Queue actors
• production runner verifies empty credentials are readable and SOLID_CACHE_MAX_SIZE_MB=17 becomes 17 MB
• render.yaml parses and contains /up without MALLOC_ARENA_MAX

Intentionally left out

• I did not set autoDeployTrigger: checksPass. The repository's current CI has only an always-green placeholder job, so checks-based deploys add no meaningful safety and risk stranding classroom-derived repositories where Actions are disabled. The Blueprint setting should be enabled with real CI.
• Supabase transaction-pooler settings, development/test URL construction, and production upload storage need separate decisions and are unchanged here.
• Several touched files are distributed by firstdraft/project-syncing; the accepted changes should be mirrored at that source so a later sync does not revert them.