You've specified padding modes for block ciphers. For block ciphers, the padding depends solely on the mode of operation and of course the block size. The paddings you mention are mainly for ECB & CBC mode of operation. Signatures however depend on a hash function, not on a block cipher. Hash functions usually perform some kind of padding internally, but that padding is not configurable.
Signatures may also pad the hash itself but that function is not intrinsic to signature schemes; a scheme without padding could well exist. For RSA we would regularly use the PKCS#1 v1.5 or PSS signature schemes, and these include a padding method of the same name (the precise names are mentioned in the PKCS#1 standard, but nobody uses that while discussing the schemes).
However, if we look at the definition of Ed448 signature scheme then we'll find the following algorithm description:
5.2.6. Sign
The inputs to the signing procedure is the private key, a 57-octet string, a flag F, which is 0 for Ed448, 1 for Ed448ph, context C of at most 255 octets, and a message M of arbitrary size.
Hash the private key, 57 octets, using SHAKE256(x, 114). Let h
denote the resulting digest. Construct the secret scalar s from
the first half of the digest, and the corresponding public key A,
as described in the previous section. Let prefix denote the
second half of the hash digest, h[57],...,h[113].
Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is
the message to be signed, F is 1 for Ed448ph, 0 for Ed448, and C
is the context to use. Interpret the 114-octet digest as a
little-endian integer r.
Compute the point [r]B. For efficiency, do this by first
reducing r modulo L, the group order of B. Let the string R be
the encoding of this point.
Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and
interpret the 114-octet digest as a little-endian integer k.
Compute S = (r + k * s) mod L. For efficiency, again reduce k
modulo L first.
Form the signature of the concatenation of R (57 octets) and the
little-endian encoding of S (57 octets; the ten most significant
bits of the final octets are always zero).
Here PH is the hash function used over the message which is a configuration option.
Note that there are two parts that could be considered padding: dom4(F, C) || prefix || PH(M) pads the hash with dom4(F, C) || prefix, and dom4(F, C) || R || A || PH(M) pads the hash with dom4(F, C) || R || A. However, neither of these two calculations are configurable (dom4 is an ASCII string, prefix is part of the hash output, R is a randomized point calculated from A and A is the public key (also a point).
All in all, no padding mode should have to be indicated for Ed448; you should just have to configure the PH, i.e. the message hash.
