Some ZIP-files generated on Windows cannot be properly extracted: the extracted files end up with a permission of `0o000`

One such ZIP-file can be downloaded via

`zipinfo -v` tells me something like this:

```
Central directory entry #1:
---------------------------

  iem_vanilla/0.INTRO.txt

  offset of local header from start of archive:   0
                                                  (0000000000000000h) bytes
  file system or operating system of origin:      MS-DOS, OS/2 or NT FAT
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2020 Oct 30 15:42:26
  32-bit CRC value (hex):                         bda8cbfe
  compressed size:                                1861 bytes
  uncompressed size:                              4899 bytes
  length of filename:                             23 characters
  length of extra field:                          0 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             text
  non-MSDOS external file attributes:             000000 hex
  MS-DOS file attributes (20 hex):                arc

  There is no file comment.
```

The problem is apparently, that the `efattr` field for the file is something like `32`, which tcllib takes as an invitation to change the permissions, but then calculates the permissions as `0`.
Cf this code for
```
    if {
	($::tcl_platform(platform) ne "windows") &&
	($fd(efattr) != 0)
    } {
	file attributes $dst -permissions \
	    [string map {0 --- 1 --x 2 -w- 3 -wx 4 r-- 5 r-x 6 rw- 7 rwx} \
		 [format %03o [expr {($fd(efattr) >> 16) & 0x1ff}]]]
    }
```

(obviously, `(32>>16)&0x1ff` evaluates to `0`.