[ZEPPELIN-6530] Fix operator precedence in SSL store path checks and make isWindowsPath null-safe

[dev-donghwan]

What is this PR for?

getKeyStorePath() and getTrustStorePath() in ZeppelinConfiguration contain
a mis-parenthesized condition:

if (path != null && path.startsWith("/") || isWindowsPath(path)) {

The condition is meant to answer a single question — "is path an absolute
path (Unix /... or Windows C:\...)?" — with path != null guarding the
whole check. But since && binds tighter than ||, it actually parses as
(path != null && path.startsWith("/")) || isWindowsPath(path), leaving
isWindowsPath(path) outside the null guard. isWindowsPath dereferences its
argument, so a null path would throw an NPE.

Note on reachability: with the current defaults this NPE is latent rather than
user-facing. ZEPPELIN_SSL_KEYSTORE_PATH has a non-null default ("keystore"),
so getKeyStorePath() never sees a null path, and getTrustStorePath() falls
back to getKeyStorePath() when the truststore path is unset. So this PR is a
correctness/hardening fix, not a fix for a currently reproducible crash.

This PR:

• restores the intended grouping in both methods —
  path != null && (path.startsWith("/") || isWindowsPath(path)) — matching
  the correctly-parenthesized pattern already used in getAbsoluteDir() in the
  same class
• makes isWindowsPath(null) return false instead of throwing, as defense
  in depth

What type of PR is it?

Bug Fix

Todos

• - Add the missing parentheses in getKeyStorePath() / getTrustStorePath()
• - Make isWindowsPath null-safe
• - Add a unit test for isWindowsPath(null)

What is the Jira issue?

• https://issues.apache.org/jira/browse/ZEPPELIN-6530

How should this be tested?

• ./mvnw test -pl zeppelin-server -Dtest=ZeppelinConfigurationTest
• The new isWindowsPathTestNull asserts isWindowsPath(null) returns false
  (it threw an NPE before this change), following the existing
  isWindowsPathTestTrue / isWindowsPathTestFalse convention.

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No — behavior is unchanged for
  all reachable inputs; only the (previously unreachable) null case changes from
  NPE to the intended relative-path fallback
• Does this needs documentation? No