CustomFormat with setDefault() Timezone does not work

**Describe the bug**
Using customFormat with timezone plugin and setting a defaultTimezone does not work.
Without a TimeZone, Safari struggles with the correct unix timestamp.

```
console.log(dayjs("02.04.1971", "DD.MM.YYYY").unix()); // Chrome: 39394800 Safari on MacOS or iOS: 39391200
```
so we tried using timezone, see Expected behavior.

**Expected behavior**
Current Setup:
```
dayjs.extend(utc);
dayjs.extend(timezone);

dayjs.extend(customParseFormat);
dayjs.tz.setDefault("Europe/Berlin");

console.log(dayjs.tz("02.04.1971", "DD.MM.YYYY", "Europe/Berlin").unix()); // correct timestamp in both browsers: 39394800
console.log(dayjs.tz("02.04.1971", "DD.MM.YYYY").unix()); // RangeError: invalid time zone: DD.MM.YYYY
console.log(dayjs.tz("1971/04/02").unix()); // correct timestamp in both browsers
```

**Information**
- Day.js Version 1.9.5
- OS: MacOS
- Browser Chrome 86, Safari 14. Unix Timestamp bug reproducible in all iOS devices
- Time zone: UTC+1 Europe/Berlin

Start at the timezone and customParseFormat plugin entry points mentioned in the report, then reproduce the three dayjs.tz calls with the Europe/Berlin default. Done means the format-only call uses the default timezone without treating DD.MM.YYYY as a timezone, while the explicit-zone and slash-form examples continue to produce the expected timestamp.

Written by the indexing model from the issue text.