model: use is None instead of falsy check in check_default_min_max

[SoundMatt]

Problem

check_default_min_max in src/vss_tools/model.py returned early
when not self.default was truthy. Python treats 0, False, "",
and [] as falsy, so a numeric signal like:

Vehicle.SomeSignal:
  type: sensor
  datatype: uint8
  description: "..."
  min: 10
  default: 0   # < min, should be rejected — but silently passed

…silently passed validation. Same for default: 0 with a negative
max. The intended range check was a no-op for any falsy default.

Fix

-        if not self.default:
+        if self.default is None:

The downstream loop already handles list-vs-scalar correctly; with
this fix, default=0 runs through the comparison and raises
ValidationError when out of range.

Test

Three new parametrize cases in tests/test_model.py:

({"datatype": "uint8", "min": 1, "default": 0}, False),   # bug case
({"datatype": "int8",  "max": -1, "default": 0}, False),  # bug case
({"datatype": "uint8", "min": 0, "default": 0}, True),    # sanity

The first two would have passed (incorrectly) before this PR. The
third confirms default=0 is still allowed when within bounds.

Notes

• Companion to model: replace assert-based validation with raise ValueError (works under python -O) #516 (assert→raise refactor in the same file). Both
  PRs harden the same model.py validators against silent failure.
• I noticed this bug while writing model: replace assert-based validation with raise ValueError (works under python -O) #516 but kept it out to keep the
  scopes separable. They can land in either order without conflict.

[sschleemilch]

That's pretty verbose. Just fix the if statement, which is a good catch

[sschleemilch]

No need for those comments. Just add the tests

[erikbosch]

MoM:

• Presented at meeting
• ok to merge after maintainer approval

[erikbosch]

@SoundMatt - will you take a look at the comments from Sebastian

[SoundMatt]

Addressed — verbose comments removed.

[erikbosch]

@sschleemilch - do you want to take a second look here