Fix offline install logic

[prabhu463]

[JENKINS-26425] Catch UnknownHostException in SetupWizard to support offline installs
Motivation
I noticed that during a fresh Jenkins install on an isolated network, the SetupWizard tries to reach updates.jenkins.io as part of its init sequence. Since this isn't currently caught, it dumps a massive UnknownHostException stack trace into the logs. For a user installing Jenkins offline, this makes the startup look like a critical failure even though the core system is actually fine.

Changes
I’ve updated SetupWizard.java to wrap the updateDefaultSite() call.

Instead of letting the exception bubble up and clutter the logs, it now catches the network failure and logs a simple INFO message.

This allows the SetupWizard to finish its initialization (creating the admin user, etc.) without making the logs look "broken."

Testing
I reproduced this locally in WSL using a network namespace to "blind" the process:
sudo unshare -n java -jar war/target/jenkins.war

Before fix: The logs showed a SEVERE stack trace during the InitReactorRunner phase.

After fix: The stack trace is gone. I see a clean INFO message: "Jenkins is starting in offline mode. Skipping initial update site refresh." and the system proceeds to the onReady state as expected.

[welcome]

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

[prabhu463]

/label bug

[daniel-beck]

GitHub shows a preview of your changes before you actually submit the pull request. You didn't look at that, otherwise you'd have noticed that you're submitting complete unrelated changes from your earlier pull request, and that you reformatted the entire file, something that #26359 points out as something not to do. You also did not notice that this PR says you changed 6 files in 3 commits since you opened it.

This lack of attention gives me little confidence you tested this properly. Given this PR is about an unnecessary log message looking worse than it is, it's not worth the effort required getting it into a mergeable shape.