docs(openspec): populate example-change + 7 EXAMPLE capability specs

[rubenvdlinde]

Summary

Fills in the previously-missing openspec/changes/example-change/ directory that the template's @spec docblock tags point at, plus the 7 openspec/specs/ capabilities those tasks implement. All files carry example: true frontmatter and a prominent "⚠️ EXAMPLE SPEC" banner so derived apps can spot the demonstration content instantly.

Why

The template's lib/**/*.php already demonstrates the @spec annotation convention with 9 tasks referenced across 10 files — but openspec/changes/example-change/ didn't exist, so every tag resolved to a dead link. Running the openspec-* skills against a fresh clone hit immediate inconsistency. This PR makes the template internally consistent without changing any code.

Produced as the second half of a test pass on Wilco's opsx-reverse-spec skill — the first half was #176 (mydash legacy-widget-bridge run). Both runs surfaced learnings that will land in a sibling PR to feature/skill-improvement after this one settles.

Capabilities added (openspec/specs/)

Capability	Source files	Implements
dashboard-page	DashboardController.php	task-1
settings-management	SettingsController.php + SettingsService.php	task-2, task-3
deep-linking	DeepLinkRegistrationListener.php	task-4
item-management	ItemController.php + ItemService.php	task-5 (item part)
configuration-initialization	Repair/InitializeSettings.php	task-5 (repair part)
admin-ui	Settings/AdminSettings.php + Sections/SettingsSection.php	task-6, task-7
observability	MetricsController.php + HealthController.php	task-8, task-9

Each spec has 1–4 REQs with GIVEN/WHEN/THEN scenarios and explicit ADR references (003, 004, 005, 006, 011). Voice matches mydash / openregister conventions ("The system MUST...").

Change scaffold (openspec/changes/example-change/)

• proposal.md — why this change exists, lifecycle guidance for apps cloning the template
• tasks.md — 9 tasks matching the @spec task-N tags in lib/
• design.md — design rationale including the known task-5 scope overlap (Item-auth + repair step share a task number; noted, not silently fixed)

What this PR does NOT do

• No lib/**/*.php files are touched. All existing @spec openspec/changes/example-change/tasks.md#task-N annotations are left as-is; they now resolve correctly.
• Does not archive the change. Archiving would move the delta into openspec/specs/ and remove the tasks, but the task file is what the code's @spec tags point at. Keeping the change in-progress (spiritually example) is what keeps the template internally consistent.
• Does not add ADRs. The specs reference ADRs by number; those ADRs live in openspec/architecture/ and are out of scope here.
• Does not add a specs/ delta inside the change directory. End-state specs live directly in openspec/specs/; duplicating as a delta would add maintenance cost without improving the demonstration.

Review focus

• Does the example: true + banner markup communicate "don't copy this as your real spec"? If not, I'm open to stronger markers (a filename suffix, a dedicated CI rule, etc).
• Is the task-5 scope overlap the right thing to document-but-not-fix? I considered splitting into task-5a / task-5b and editing three docblocks, but that felt like scope creep for a documentation PR.
• Voice consistency with other OpenSpec capabilities (mydash has 9 capabilities using the same format — I followed it).

Test plan

• @WilcoLouwerse review the example markers — strong enough?
• Optional: run any openspec-* skill against this branch to confirm tasks/specs resolve cleanly.
• Optional: grep lib/ for @spec example-change — all 15 references should match a task in tasks.md.

Related

• #176 — opsx-reverse-spec learnings from the mydash run (sibling to this)
• #177 — opsx-coverage-scan learnings (same)
• A combined learnings PR with findings from both mydash + this template run will follow; app-versions is next up for a third data point.