Make SketchedToolServiceImpl.onStart non-blocking (265.66ms → 0.56ms)

[ankitsharma101]

What it does

SketchedToolServiceImpl.onStart() was previously async and blocked the frontend startup sequence while it resolved the config directory and read sketchedTools.yml from disk. Since Theia's startContributions loop awaits each FrontendApplicationContribution.onStart() sequentially, this added the full I/O cost directly to every contribution that started afterward.

This PR makes onStart() fire-and-forget, delegating the actual work to a new protected async doStart(). Tools still register automatically once doStart() completes; startup no longer waits on it. This mirrors the existing pattern in McpFrontendApplicationContribution.onStart().

Note: errors from doStart() are now caught and logged (this.logger.error(...)) rather than propagating to the framework's startContributions await chain — consistent with how McpFrontendApplicationContribution handles the same situation.

How to test

1. Capture a Chrome DevTools Performance trace of a cold Theia startup (record before launch, stop well after the UI settles).
2. Extract the blink.user_timing marks for SketchedToolServiceImpl.onStart.
3. Before this change: ~265.66ms (blocking on file resolve + disk read).
4. After this change: ~0.56ms (fire-and-forget), matching McpFrontendApplicationContribution.onStart (~0.45ms) as a reference point.
5. Confirm sketchpad tools still register correctly after startup — the deferred doStart() work still completes (verified via the SketchedToolServiceImpl.settled-start marker firing normally after startContributions begins).

Follow-ups

None.

Breaking changes

• This PR introduces breaking changes and requires careful review.

Attribution

None

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed [the review guidelines
• User-facing text is internationalized using the nls service

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines