v0.3.77 — Stop mistaking the API update recovery flag for a blocker

v0.3.77 — Stop mistaking the API update recovery flag for a blocker

Why this matters

XUUnity could read Unity's -accept-apiupdate launch option from Editor.log and report it as evidence that the API Updater was blocking startup. That option is supplied to let a non-interactive launch accept API updates, so the health report could send a developer toward the wrong recovery step.

What changed

• Editor-log health diagnoses now identify themselves as heuristic pattern matches, which means they are leads inferred from log text rather than measured dialog or compile state.
• The -accept-apiupdate command-line option no longer produces api_updater_activity_observed by itself.
• Real updater markers such as [API Updater], API Update Required, and UnityUpgradable remain detectable, including when the recovery flag is present in the same log.

What this gives developers

• A normal non-interactive recovery launch no longer looks like the updater problem it was intended to avoid.
• Health output states the evidence level explicitly, making it clearer when to verify current editor state before acting on a log-derived diagnosis.

Validation

• Focused host regression suites passed: 51 tests covering project health and tool argument contracts; the final project-health-only rerun passed 18/18.
• The full host suite ran 1,095 tests: 1,089 passed in the sandbox, while six loopback-bind cases were blocked by sandbox permissions; the complete TCP transport suite then passed 11/11 with loopback access.
• Public release checks passed for version consistency, documentation freshness, public-safety scanning, release-commit shape, and clean diffs.
• Public-site browser checks passed 42/42 against the v0.3.77 documentation surfaces.
• Unity 6000.0.58f2 consumer validation passed all six Android/iOS build-profile compile pairs, bridge health, the 10/10 acceptance scenario, the contract scenario, and PlayMode lifecycle checks.

Known limitations

• Unity Package CI is waived because the GitHub runners have no Unity license secrets, so this release SHA has no CI-recorded package EditMode/PlayMode proof. Local Unity 6000.0.58f2 consumer validation is reported separately above.
• A trailing project-specific action-catalog consistency check reported four existing currency payload-normalization cases after the primary Unity validation suite passed. This release does not change project-action normalization.
• A Unity 2022.3.62f3 consumer project had its XUUnity bridge disabled, so no live MCP consumer proof was claimed for that project. The released change is in the Python host diagnosis path, not the Unity/C# package.