fix: capacity commitment report broken in demo mode

[accorvin]

Add missing jiraTeam field-options fixture so demo mode serves a 200 instead of 404. Also make fetchFieldOptions non-fatal in CapacityCommitmentReport — matching the pattern already used by ProgramHygieneReport and ExecuteWorkspaceView — so a field-options failure never blocks the entire report UI.

Fixes #1522

Generated with Claude Code

[claude]

Claude finished @accorvin's task in 2m 41s —— View job

---

PR Review: fix: capacity commitment report broken in demo mode

• Check out PR branch and read review instructions
• Read the diff and changed files
• Validate against project conventions and hard constraints
• Report findings and set verdict

---

Review Summary

Verdict: PASS — no blocking issues found.

This PR makes three changes:

1. New fixture fixtures/team-data/field-options/jiraTeam.json — Adds the missing jiraTeam field-options fixture so demo-storage can serve it (200) instead of returning null (404). Format matches the existing component.json fixture from core. The demo-storage findInFixtures() resolves this by relative path, so no explicit registration in module.json is needed. Looks good.

2. CapacityCommitmentReport.vue catch block — Changes fetchFieldOptions from fatal (error.value = e.message) to non-fatal (silent catch with comment). This matches the identical pattern already used in ProgramHygieneReport.vue (lines 115-117). The report gracefully falls back to values derived from loaded features, so losing curated field-options data only degrades filter completeness, not core functionality. Correct fix.

3. platform/view-owners/owners.js cleanup — Removes stale team-tracker view-owner entries. Since team-tracker moved to @org-pulse/core, the update-view-owners.js script (which this file says generates it) can't find git history for those views locally, making these entries stale. This cleanup is tangential to the stated fix but harmless — getViewOwner() returns null for these views, which just means no owner badge, consistent with other core-owned views.

No security, correctness, performance, or hard-constraint issues found. No changes needed.

---

[accorvin]

Closing this as I didn't realize #1524 had already been opened.