Emit a single template when the site plan creates posts

## Problem

`WordPressSitePlan::templates()` emits `index.html`, `page.html`, and optionally `front-page.html`, but never emits `single.html` when imported documents are classified as WordPress posts.

WordPress therefore resolves an imported post through the generated archive `index.html`, which renders a Query loop with title, excerpt, and date instead of the post's stored block content. Automattic/studio#3952 Puffin acceptance materialized the post correctly with 412 KB of block content, but its permalink rendered only the archive summary.

## Acceptance criteria

- A site plan containing at least one `post_type: post` emits `templates/single.html`.
- `single.html` uses `wp:post-content` and the same applicable shared shell placement rules as page templates.
- Page-only plans do not gain unnecessary post templates.
- A WordPress-backed fixture proves the imported post permalink renders its stored content rather than the archive loop.
- Existing template-surface, parity, and package-install contracts pass.

## AI assistance

OpenAI gpt-5.6-sol via OpenCode traced the imported post from the site plan through WordPress template hierarchy and frontend output, identified the missing `single.html` generation path, and drafted this issue. Chris Huber directed the investigation and remains responsible for the scope.

Start at WordPressSitePlan::templates() and trace how post_type: post documents affect generated templates and shared shell placement. Use the WordPress-backed fixture to verify an imported post permalink renders stored block content, then run the template-surface, parity, and package-install contracts; page-only plans must remain unchanged.

Written by the indexing model from the issue text.