Remove the dead DAL 2.0 custom post type handling

> *This was generated by AI during triage.*

### Background

The DAL 2.0 custom post types (`zerobs_customer`, `zerobs_quote`, `zerobs_invoice`, `zerobs_company`, `zerobs_transaction`, `zerobs_form`, `zerobs_event`, `zerobs_quo_template`) are not registered anywhere in the plugin. `register_post_type` does not appear in the plugin's own PHP in any of this repo's 1,509 commits, so they were already gone when CRM was added to the Jetpack monorepo in January 2023. The removal happened in the pre-monorepo history, during the move to custom tables.

The code that handled them is still here. It cannot run, because `get_post_type()` never returns any of those values and WordPress will not route `post.php` or `edit.php` to an unregistered type.

Found while investigating #15.

### The trap

`'zerobs_customer'` and its siblings appear in roughly 200 places across 45 files, and **most of those are live code**. The same strings are used for three different things:

1. **DAL object-type strings.** Throughout the DAL, logging, and the MailPoet and portal modules. Live, load-bearing.
2. **A WordPress user role.** `zerobs_customer` is a role name, checked in the portal router.
3. **Actual post types.** The dead subset.

A grep-and-delete pass would break the plugin badly. The removal has to be driven by context, not by the string.

### What is genuinely dead

Post-type usages with no registered type behind them:

- `zeroBSCRM_add_admin_styles()` in `ZeroBSCRM.ScriptsStyles.php`: the `$post->post_type` and `$_GET['post_type']` branches, and the `zbs_extra_custeditscripts` action inside them. That action's replacement, `zbs_postenqueue_editview`, is live elsewhere in the same file and carries a comment naming the old hook, so extensions were migrated across deliberately.
- `zeroBSCRM_is_ZBS_custom_post_page()` in `ZeroBSCRM.AdminPages.Checks.php`, plus the sibling `zeroBSCRM_is_customer_edit_page()` checks and their callers in `ZeroBSCRM.MetaBoxes3.Contacts.php` and `class-learn-menu.php`. All now always false.
- The `post_updated_messages` filter arrays in `ZeroBSCRM.AdminStyling.php`. WordPress only uses these for registered types.
- `remove_meta_box( 'submitdiv', 'zerobs_invoice', 'core' )` in `ZeroBSCRM.InvoiceBuilder.php`.
- The `WP_Query` with `'post_type' => 'zerobs_customer'` in `ZeroBSCRM.CustomerFilters.php`.
- Commented-out SQL against `$wpdb->posts` in `ZeroBSCRM.DAL3.Helpers.php`.

### What must stay

- **`zeroBSCRM_database_reset()` in `ZeroBSCRM.Database.php`.** It deletes leftover DAL 2.0 rows from `$wpdb->posts` for these post types. Installs that upgraded from 2.x still have those rows, and this is the only thing that clears them. The post types being unregistered is exactly why the rows are orphaned, not a reason to stop deleting them.
- Every DAL object-type and user-role usage from the three categories above.

### A related bug in the same function

`zeroBSCRM_add_admin_styles()` opens with:

```php
if ( $hook == 'post-new.php' || $hook == 'post.php' || $hook == 'edit-tags.php' || 'edit.php' ) {
```

The last term is a bare truthy string, so the condition is always true regardless of `$hook`. It has no visible effect today because the inner branches all fail, but it should go with the rest.

### Side effect worth confirming

`edit.php?post_type=zerobs_customer` currently returns a 500. Nothing in the UI links to it, and the URL only appears in `post_updated_messages` strings that never render. Worth checking whether anything else still generates such a link before or after the cleanup.

### Why this is not `ready-for-agent`

The keep-versus-remove boundary needs judgment, particularly around `zeroBSCRM_database_reset()` and anywhere the same string is doing DAL work. An agent working from a grep would be likely to over-reach. Someone should decide the boundary first, and it may be worth splitting into a few smaller passes by file.

### Extension impact

Low. Anything relying on these being real post types has been broken for over three years, so removing the handlers cannot make it worse. The one public function that disappears is `zeroBSCRM_is_ZBS_custom_post_page()`, which returns false for every caller today and would continue to behave identically if callers were left with the constant.

Review the named handlers in ZeroBSCRM.ScriptsStyles.php, ZeroBSCRM.AdminPages.Checks.php, ZeroBSCRM.MetaBoxes3.Contacts.php, class-learn-menu.php, ZeroBSCRM.AdminStyling.php, ZeroBSCRM.InvoiceBuilder.php, ZeroBSCRM.CustomerFilters.php, and ZeroBSCRM.DAL3.Helpers.php. Confirm the dead post-type branches and the edit.php URL behavior while preserving zeroBSCRM_database_reset() and all DAL and role usages. Done means only genuinely unreachable post-type handling is removed without changing live behavior.

Written by the indexing model from the issue text.