Base theme no longer recognized

Question

I recently inherited a Drupal 7 (7.39) site using an old version of Omega 4 (beta7) and a custom subtheme. All was well until this morning, when cron got stuck. It unstuck itself before I could start work, but now Drupal no longer recognizes the Omega base theme, so classes and other theme variables are not inserted properly, and the display is a mess.

To clarify,

• I have cleared all caches from admin_menu and Devel many times (we are on shared hosting and there is no shell/Drush access).
• There are no unusual errors or warnings on the status report or watchdog.
• There have been no configuration changes within Drupal or on the server, which is running PHP 5.5.29 and Percona 5.6.28.
• There are no Omega- or other theme-related modules installed except CiviCRM Theme, which I have disabled to no effect.
• The files are all still present in /sites/all/themes/omega and /sites/all/themes/oursubtheme , and completely untouched as far as I can tell (no changes in file sizes or date stamps for as far back as we have snapshots).
• As it's shared hosting, all files are owned by the account user with permissions set to 775. Again, this is not something that has changed.
• the subthemes (both Ohm, the bundled subtheme, and our custom one) show up on the /admin/appearance screen just fine, but Omega itself does not.
• I can get to the settings screens for the subthemes, e.g. /admin/appearance/settings/ohm, just fine. But browsing /admin/appearance/settings/omega returns an Access Denied error.
• But Drupal must know that Omega is installed, because when I look at /admin/reports/updates or /admin/appearance/update, it shows up on the list of themes with updates available.
• The pending updates for Omega are not security-related, so I don't think that it is a situation where it is being disabled or disallowed by a security mechanism

Naturally, the timing could not be worse for this to happen to the client, so I would appreciate any ideas as to what could cause Drupal to "lose" a theme like this, or how we might jog its memory.

Answer 1

I ran _system_rebuild_theme_data() but that didn't seem to improve the situation, so I checked the theme status in the system table; the base theme had been disabled. There lay the rub.

How or why the base theme became disabled remains a mystery. At the time this site was built, it was not required for a base theme to be enabled for the subtheme to access its functions; this changed, but I hadn't touched the theme in the month I've been working on this site, other than rebuilding the cache, so presumably it had been enabled before.

Since Omega was disabled, it was not supplying the right theme variables for our custom subtheme (though .tpl.php files did seem to get found), thus the broken display this morning.

Because Omega 4 is designed to be built and configured programmatically, perhaps, the base theme is hidden by default, and there was no way to enable it from the UI. I had to edit the .info file so that it was no longer hidden, at which point it showed up on /admin/appearance as usual.

If I had been able to use Drush on this server, this all would have been a non-issue. Many thanks to @Clive for his quick response and suggestions.