api_keys.html uses `{% block content %}`, which consuming sites' Studio bases do not define

Found while fixing the consuming-site symptom in AI-Shipping-Labs/website#1737.

community_base/api/api_keys.html puts its whole body in {% block content %}. A consuming site whose Studio base defines a differently-named block — AI Shipping Labs' templates/studio/base.html defines {% block studio_content %} — silently drops the entire page body. The result is HTTP 200 with a correct page title and an otherwise empty shell: no create form, no key list, no revoke control, and no error anywhere to notice.

On AI Shipping Labs this meant /studio/api-keys/ has been non-functional since the package URLs were mounted, with the only issuing path for a package API key being a production shell. The POST route is unaffected and still works when hit directly.

DataTalksClub/website mounts the same package URLs and has the same latent failure; worth checking whether it renders there or is silently blank too.

AI Shipping Labs is fixing its own side by taking ownership of the view (it also needs to scope an unfiltered queryset, which a template-only change cannot do), and is deliberately not blocking that fix on a package release. Filing here so the package template does not keep shipping a block name that consuming sites are not required to define — either agree a contract for the block name, or have the package template extend a base the site is expected to provide.

Start with community_base/api/api_keys.html and compare its block inheritance with AI Shipping Labs' templates/studio/base.html; inspect how the mounted package URLs render the page. Check the corresponding DataTalksClub/website rendering if available. Done means the block contract is agreed and the API keys page retains its create form, key list, revoke control, and errors in consuming sites.