Centralise remaining marketing copy: Play Store URL and feature cards vs llms.txt

## Summary

Two pieces of website marketing copy remain uncentralised, per the jazzjam-workbench README's "V2 candidates (known duplication not yet centralised)" section:

1. **Play Store URL** — hardcoded 3 times in `src/index.html` (currently lines 861, 867, 975), each carrying the same UTM parameters. A URL or UTM change means three coordinated hand edits.
2. **Marketing feature cards** — the feature wording has drifted between `src/index.html` and `src/llms.txt`, which are maintained by hand in parallel. They need a copy decision first (which wording wins), then a single source rendering both.

## Business Value

The website is the public face of the product; drifted feature descriptions between the human-facing page and the LLM-facing `llms.txt` mean different audiences are told different things about the same app. Centralising the Play Store URL removes a three-place failure mode on the single most important outbound link (the install CTA), and templating `llms.txt` guarantees the marketing cards can never drift again.

## Scope

### In scope
- Centralise the Play Store URL (including UTM parameters) into a single data source consumed by all 3 occurrences in `src/index.html`
- Make the copy decision reconciling the feature-card wording between `src/index.html` and `src/llms.txt` (which wording wins, per card)
- Template `src/llms.txt` from the centralised copy via an Eleventy permalink template, so both surfaces render from one source
- Decide where the single source lives (site data file vs. workbench `content/shared.json` + `npm run sync`) — implementation approach is the developer's call; content shared with the app belongs in the workbench

### Out of scope
- The Pro Unlock section content (centralised already; the All Keys Cycle addition is a separate iteration issue)
- Any pricing — prices come from RevenueCat at runtime; a Playwright test fails the site on hardcoded pricing
- App-side copy (see amypellegrini/musicpracticepro#663 for the paywall hero copy)
- Release-notes tooling duplication (separate V2 candidate)

## Acceptance Criteria

- [ ] The Play Store URL appears in exactly one source location; all 3 render sites in `src/index.html` consume it, and changing it in one place updates all occurrences
- [ ] A documented copy decision reconciles the feature-card wording between `index.html` and `llms.txt`
- [ ] `src/llms.txt` is generated via an Eleventy permalink template from the same source as the feature cards — no hand-maintained duplicate wording remains
- [ ] Rendered output is byte-equivalent in intent: the built site's feature cards and the built `llms.txt` describe the same features in the agreed wording
- [ ] Playwright suite green, including the no-pricing guard

## Manual Verification

1. Change the Play Store URL's UTM parameter in its single source, rebuild the site, and confirm all 3 links in the built homepage carry the change; revert
2. Edit one feature-card description in the single source, rebuild, and confirm both the homepage card and the built `/llms.txt` reflect the edit; revert
3. Confirm `src/llms.txt` no longer exists as hand-maintained duplicated copy (it is produced by the template)
4. Run the Playwright suite and confirm it passes

## Related issues

- amypellegrini/musicpracticepro#663 — centralise the app paywall hero copy (sibling backlog item from the same workbench "V2 candidates" list)
- Workbench README "V2 candidates" section documents this duplication; if the source of truth ends up in the workbench, the change flows through `content/shared.json` + `npm run sync`

Start by reading src/index.html, src/llms.txt, and the README's V2 candidates section, then inspect the existing build and npm run sync entry points. Resolve the feature-card wording and shared-source location before rebuilding. Done means the three homepage links and both rendered content surfaces use the single source, src/llms.txt is generated, and the Playwright suite passes.

索引モデルが issue の本文から書いたものです。