Why does forge verify-contract need --constructor-args?

[CodeSandwich]

The short answer is probably "because the block scanners APIs require it", but why is this and can't it be bypassed? forge verify-contract would be so much easier to use if it accepted just the address and the contract name, without reconstructing the list of arguments. I'm aware of the --guess-constructor-args, but it only works with transactions directly deploying contracts, so it leaves many scenarios uncovered.

The block scanner obtains the init bytecode by tracing the execution of the transaction, so the deployment doesn't need to be done by explicitly sending the bytecode to the null address in a separate transaction. The init bytecode is then compared with the bytecode constructed by concatenating the result of compilation of the submitted source code and the constructor arguments. (right?)

It seems that the constructor arguments are redundant in the verification of the compiled source code part of the init bytecode. The init bytecode must only start with the entire compiled source code, the rest are the constructor arguments provided by the contract verifier. The arguments are arbitrary, they can be forged by the submitter to match the init bytecode, so it doesn't add any security.

[CodeSandwich]

It turns out that forge verify-contract doesn't really need --constructor-args. For Sourcify this parameter is completely ignored, so the constructor args must be inferred as described in the question. Constructor args are only needed for Etherscan and derivatives, it's entirely this platform's quirk. Blockscout seems to be a derivative too, but it exposes the autodetectConstructorArguments flag which seems to be set to true by default.