Problem

Closes #13192. Opening a subject page (/subjects/<name>) intermittently crashes with TypeError: %d format: a real number is required, not NoneType, falling back to the default error template, when Solr errors or is slow to respond.

Root cause

SearchResponse.from_solr_result() (openlibrary/plugins/worksearch/code.py) sets num_found=None + error=<msg> as a paired sentinel whenever the Solr query itself errors. SubjectEngine.get_subject_async() (openlibrary/plugins/worksearch/subjects.py) propagated result.num_found straight into page.work_count with no guard, and subjects.html's $ungettext(..., page.work_count, count=page.work_count) cannot format None.

Fix

• Subject now carries error (propagated from result.error).
• subjects.GET() checks subj.error explicitly and renders a new subjects/unavailable.html template with a 503 status — a distinct "temporarily unavailable" state — instead of falling through to the crash-prone subjects.html template, or to the existing 404 notfound.html (which would misrepresent a transient Solr error as "this subject has zero books").
• This matches the existing convention elsewhere in the codebase (search/subjects.html, search/lists.html, search/authors.html) of checking response.error and surfacing it rather than silently treating an error as zero results.

Testing

• New tests in openlibrary/plugins/worksearch/tests/test_subjects.py:
  • get_subject_async propagates result.error onto the Subject when Solr errors (mocked run_solr_query_async).
  • subjects.GET() routes an errored subject to the unavailable template + 503, not the crash path or the notfound path.
  • Regression: a genuine zero-result subject (no error) still 404s via notfound.html, unaffected.
• Full openlibrary/plugins/worksearch/ suite passes (74 tests).
• Manual Docker verification pending — will update this description once complete.