Simultaneous with these symptoms, we got an HTTP 403.14 when browsing to the root (e.g. http://dev-intranet/)

Resolved by:
1. detaching content database of the affected site (central admin > application mgmt > content databases, Remove Content Database)
2. create new web application (central admin > application mgmt > create or extend web app > create new web app) with mostly defaults except database authentication & search server
3. created a new site collection in this new web application * observe the ability to get to this new site (central admin > application mgmt > create site collection)
4. detach the database of the new site (central admin > application mgmt > content databases, Remove Content Database)
5. stsadm -o addcontentdb -url http://NewSiteURL -databasename DetachedOriginalContentDB (apparently the attach aspx times out with large databases or is otherwise flaky)
6. go to the crawl log (shared services admin > search settings, view crawl log) * observe crawler sailing through new application’s content database
7. edit bindings in IIS manager of the old non-functional Site, change the port to something unused and random, and remove the hostname (i.e. if its mapped to a DNS entry this is the host header info)
8. edit bindings in IIS manager of the newly created functional Site, change the hostname, port, IP address to the desired final state/match the DNS entry (e.g. hostname=dev-intranet, port=80)
9. edit alternate access mappings (central admin > operations > alternate access mappings, edit public URLs for the Collection that was just created in step 2; if your crawl is in progress, move the Default URL to the Intranet URL space. Enter the IIS binding name/host header (step into the Default URL

And kung-fu support from microsoft was required to get us back up. Route questions about this resolution to @pritish on twitter.