Register core post SEO meta fields via register_post_meta for REST API exposure

### Description

Issue #161's MVP requirements call for custom meta fields to be exposed in the REST API, noting this should come for free "as long as the fields are registered with WP." Newer feature fields already get this: `register_meta_helper()` (`src/meta.php`) defaults `show_in_rest` to `true` and is used consistently by Open Graph (`wp_seo_open_graph_*`), Twitter Card (`wp_seo_twitter_card_*`), and the config-driven fields in `config/post-meta.json`.

However, the plugin's original/core fields — `_meta_title`, `_meta_description`, `_meta_canonical_url`, and `_meta_robots_{directive}` — are set and read exclusively via raw `get_post_meta()`/`update_post_meta()` calls in `php/class-wp-seo.php` and are never passed through `register_post_meta()`/`register_meta_helper()` anywhere in the codebase. They are therefore invisible to the REST API today.

Separately, all per-term SEO data (title/description/canonical/robots) is stored as a single serialized `wp_options` row keyed `wp-seo-term-{term_taxonomy_id}` (see `WP_SEO::get_term_option_name()`), not as real term meta, so it structurally cannot be exposed via `register_term_meta()` without a data-model change.

### Use Case

Headless/decoupled front ends and any tooling that reads post data via the REST API need access to the core SEO fields (title override, meta description, canonical URL, robots directives) — not just the newer Open Graph/Twitter fields — without having to fall back to custom REST endpoints.

### Proposed Solution

- Register `_meta_title`, `_meta_description`, `_meta_canonical_url`, and `_meta_robots_{directive}` via the existing `register_meta_helper()` (`src/meta.php`) so they pick up `show_in_rest` consistently with the rest of the plugin's fields, updating `WP_SEO::save_post_fields()`/the meta box save path as needed so both write paths stay in sync.
- As a separate, follow-up consideration (not required to close this issue): evaluate migrating per-term SEO data off the single serialized `wp-seo-term-{id}` option and onto real term meta via `register_term_meta()`, which would be required before term-level SEO data could ever be REST-exposed the same way.

### Related

- #161 (parent MVP tracking issue)