Build releases from pull request notes

[kingpanther13]

What does this PR do?

• replaces the hard-coded HACS release sentence with notes taken from the exact merged pull request
• adds a fail-closed parser for missing, blank, placeholder, ambiguous, or unrelated release-note data
• adds a lightweight Release Notes check that reruns when a pull request body is edited
• keeps the commit-to-PR API permission least-privileged and supports unambiguous rebase associations
• verifies the bundled 256x256 PNG through Home Assistant's real authenticated local-brands proxy in the HAOS E2E lane
• replaces the incomplete source-only HACS seed with the supported Get HACS add-on bootstrap and requires the HACS entry to reach loaded
• keys the HAOS image cache to the current ESPHome add-on, Get HACS add-on, and latest HACS release
• tolerates a transient webhook outage only while polling the idempotent live-device registry reads, while preserving a bounded hard failure
• bumps the component to 0.1.4 so this merge exercises the complete GitHub release-publication path

The published v0.1.3 release body was also corrected directly to describe the FastMCP startup-collision fix from PR #15.

Release notes

• GitHub releases now publish the merged pull request's user-facing release notes instead of a generic HACS installation sentence.
• Version-bump pull requests now fail CI when release notes are missing or placeholders, including after the pull request body is edited.
• Release publication now fails closed if GitHub cannot identify one merged pull request for the release commit.
• The bundled ESPHome MCP icon is now regression-tested through Home Assistant's authenticated local-brands API, including a byte-for-byte check of the image served from the installed custom component.

Type of change

• Bug fix
• New feature
• Documentation
• Maintenance/refactor
• Breaking change

Testing

• Unit tests pass (141 passed locally and in CI)
• Ruff check and format checks pass
• Release metadata and version-bump guards pass for 0.1.4
• All workflow YAML parses successfully
• HAOS E2E passes on a freshly rebuilt image with current HACS installed and loaded
• HAOS E2E retrieves the local icon through brands/access_token and compares it byte-for-byte
• HAOS E2E exercises the ESPHome registry, live host device, Device Builder ingress, YAML, validation, logs, compile, install, and firmware-job paths
• HACS, Hassfest, host-device E2E, dependency sandbox, and all remaining required checks pass

HACS icon status

The component ships custom_components/esphome_mcp/brand/icon.png, the supported location for Home Assistant 2026.3 and newer. The HAOS lane exercises the actual brands/access_token WebSocket command and /api/brands/integration/esphome_mcp/icon.png endpoint, comparing the response byte-for-byte with the bundled icon. It also installs the complete current HACS release through the same Get HACS add-on path used by ha-mcp and fails unless HACS loads successfully.

That proves the repository and Home Assistant side. The released HACS 2.0.5 Downloads dashboard still constructs legacy public Brands CDN URLs, so it cannot display inline custom-integration icons yet. That HACS defect remains open in hacs/integration#5223; its fix is the unmerged hacs/frontend#937. No change in this repository can replace the URL generated inside HACS's frontend bundle.

Checklist

• Documentation was updated if needed
• HACS metadata and release workflow behavior were considered if install/release behavior changed
• ESPHome Device Builder behavior was considered if tool behavior changed