MCP commits only register on the Work Item when its page is opened in the UI

Follow-up to #20: commits made via the MCP tool reach the GitHub branch, but the org records are only created when someone opens the Work Item page in the UI. Until then the change list is empty/stale — indefinitely.

**Evidence (prod, API v67.0):** `CommitDate` vs `CreatedDate` gaps of 4.5 min to **~26 h**; three commits across two Work Items all registered in the same 7-second window = the moment the pages were opened; `DevopsActivityLog` COMMIT rows have `ActivityDate` = real commit time but `CreatedDate` = UI-open time.

**Repro:** commit via MCP, don't open the UI → `SELECT Id FROM WorkItemComponentList WHERE WorkItemId=''` returns 0 rows forever; open the Work Item page → rows appear instantly.

**Expected:** register components at commit time, or expose an API to trigger the refresh headlessly (MCP/CI can't rely on a human clicking). Also unclear whether promotions read the live branch or these stale records — if the latter, this is more than cosmetic.

---

### Full Details Below
_(written by Claude Code)_

## Summary

Follow-up to #20. Commits made with the Salesforce DX MCP tool `commit_devops_center_work_item` do now appear in the Work Item change list (thanks for that fix!), but the registration is **lazy**: the org-side records (`WorkItemComponentList`, `WorkItemComponent`, and the `COMMIT_STARTED`/`COMMIT_COMPONENT`/`COMMIT_COMPLETED` rows in `DevopsActivityLog`) are only created **when a user opens the Work Item page in the DevOps Center UI**. Until someone clicks, the change list is empty or stale — indefinitely.

For headless / agent-driven workflows (the whole point of the MCP tools), this means the Work Item's component data in the org cannot be trusted without a manual UI visit.

## Evidence (production org, API v67.0, GitHub-hosted repo)

All commits below were made via `commit_devops_center_work_item`. Comparing the git commit time (`WorkItemComponentList.CommitDate`) against when the org actually created the record (`CreatedDate`):

| Work Item | Commit | CommitDate (git) | CreatedDate (registered in org) | Gap |
|---|---|---|---|---|
| WI-A | `0b0d5f84` | 2026-08-16T14:36:40Z | 2026-08-17T16:33:44Z | **~26 h** |
| WI-A | `cbeb387c` | 2026-08-17T15:16:29Z | 2026-08-17T16:33:44Z | 77 min |
| WI-B | `08d64fbf` | 2026-08-17T16:29:22Z | 2026-08-17T16:33:50Z | 4.5 min |
| WI-C | `6ffb459e` | 2026-08-18T19:10:33Z | 2026-08-18T20:05:31Z | 55 min |
| WI-C | `308528ba` | 2026-08-19T08:29:19Z | 2026-08-19T10:08:16Z | 99 min |

Two things pin the trigger to the UI page load:

1. Three commits across two different Work Items (WI-A ×2, WI-B ×1) all registered inside the **same 7-second window** (16:33:44–16:33:51 on Aug 17) — exactly when those Work Items were opened in the UI. Registration time correlates with the page visit, not with the commits, which were made 26 h, 77 min and 4.5 min earlier respectively.
2. `DevopsActivityLog` shows it directly: the `COMMIT_STARTED`/`COMMIT_COMPONENT`/`COMMIT_COMPLETED` rows have `ActivityDate` = the real commit time but `CreatedDate` = the UI-open time. Example (WI-A, first commit):

```
ActivityType: COMMIT_COMPONENT
Description: {"componentName":"MyClass","componentType":"ApexClass","operation":"CHANGE"}
ActivityDate: 2026-08-16T14:36:40Z <- real commit time (backdated)
CreatedDate: 2026-08-17T16:33:44Z <- when the WI page was opened
```

## Steps to reproduce

1. Create a Work Item in next-gen DevOps Center and commit any change to it via the MCP tool `commit_devops_center_work_item` (commit lands fine on the `WI-######` branch in GitHub).
2. Do **not** open the Work Item in the UI. Query the org:
`SELECT Id FROM WorkItemComponentList WHERE WorkItemId = ''` → 0 rows, no matter how long you wait.
3. Open the Work Item page in DevOps Center → the change list populates immediately; the new rows have `CreatedDate` = now and `CommitDate` = the original commit time.

_CreatedDate is a couples of minutes later than commit because the WorkItem was opened in the UX_

Without opening the WI, this SOQL will return No Records - forever

## Expected behaviour

Components are registered at (or shortly after) commit time regardless of whether the UI is ever opened — or, at minimum, a documented API exists to trigger the registration/refresh headlessly, so MCP/CI workflows can call it after committing.

## Actual behaviour

Registration only happens as a side effect of the Work Item page loading in the UI.

## Impact

- Agent/headless workflows see an empty or stale change list on the Work Item until a human clicks — the org data can't be used to verify what a Work Item contains.
- It is unclear whether downstream operations (promotion component sets, destructive-change detection) read the live branch or the registered component records — if the latter, this is more than cosmetic. We haven't tested promoting without opening the UI first.
- `DevopsActivityLog` rows are created late with backdated `ActivityDate` (`CreatedDate` ≠ `ActivityDate`), which makes commit auditing confusing.

## Environment

- Next-gen DevOps Center (standard objects: `WorkItem`, `WorkItemComponentList`, `WorkItemComponent`, `DevopsActivityLog`), production org, API v67.0
- GitHub-hosted repo
- Salesforce DX MCP server, tool `commit_devops_center_work_item`

Related: #20

One operational takeaway for us regardless of the fix: the devops-promotions skill's component-list check reads this same lazy data — until Salesforce fixes it, open the Work Item in the UI before trusting any change-list verification. Say the word if you want that noted in the skill.

Start with the commit_devops_center_work_item flow and the devops-promotions skill's component-list check. Reproduce the issue without opening the Work Item UI, then compare the resulting WorkItemComponentList and DevopsActivityLog records with the UI-open case. Done requires commit-time registration or a documented headless refresh, with promotion behavior verified.

Written by the indexing model from the issue text.