occ user:welcome omits the password reset link by default, while occ user:add always includes it

Bug description

The two invitation paths of the same instance send different welcome emails, and the one an
operator reaches for after a failed send is the one that cannot be acted on.

• core/Command/User/Add.php:187 calls generateTemplate($user, true) — the reset-password
  link is always included.
• core/Command/User/Welcome.php:72 calls
  generateTemplate($user, $input->getOption('reset-password')) — the link is included only if
  -r / --reset-password is passed.

Without that option, occ user:welcome sends a well-formed welcome email whose button points at
the instance root, which immediately redirects to the login page. The recipient has no password
yet and no way to set one, so the invitation is a dead end. Their only route is "forgot
password", which is precisely what the invitation was supposed to spare them.

Why this matters more than a default

This composes with #64151. There, occ user:add reports Welcome email sent even when the mail
never left, because the transport failure is swallowed. The operator sees success, the user
receives nothing, and the natural recovery is to re-send with occ user:welcome <uid>.

That re-send is the one without the link. So the sequence an operator most plausibly follows —
create, believe it worked, discover it did not, re-send — produces an email that cannot be used.
Both commands read as the obvious thing to run, and neither warns.

Steps to reproduce

1. occ user:add --display-name "Test" --email test@example.org testuser
2. occ user:welcome testuser
3. Open the email and click the button.

Expected behaviour

Either the two paths agree, or occ user:welcome says what it is about to send. Concretely, one
of:

• default user:welcome to including the reset link, matching user:add, with an opt-out for
  the case where the account already has a password; or
• keep the current default and print a one-line notice when the link is omitted, e.g.
  Sending without a password reset link (use --reset-password to include one).

Actual behaviour

The email is sent, the command exits 0, and nothing indicates that the button leads to a login
page the recipient cannot pass.

Nextcloud version

34.0.3 (34.0.3.2), official Docker image. Both call sites were read in the running container.

Start with core/Command/User/Add.php:187 and core/Command/User/Welcome.php:72, comparing how each command passes the reset-password choice to generateTemplate(). Decide which documented behavior should apply to user:welcome, then verify the welcome email and command output match that behavior for both reset-link and no-link cases.