the authorization function in your first example const authorization = fcl.currentUser().authorization is a function that implements the second one, but instead of signing the transaction directly using a known private key, it asynchronously sends what needs to be signed to the wallet (via instructions fcl received during authentication), the wallet then signs it and then sends back the signature.
We call this an authorization function. It has the signature authFn :: account -> account where account = { addr, keyId, signingFunction, roles } and signingFunction :: signable -> compositeSignature
fcl.currentUser().authorization more or less looks like this:
Where requestSignatureFromWallet triggers the iframe and all that which allows the user to approve the transaction.
The authorization function works in two steps, the first tells the transaction which address and keyId are going to be signing as well as how to get a signature for that address/keyId. The second step gets the signature using that who (address/keyId) and how (signingFunction) specified in the first step. These two steps need to happen because the data that is signed includes who needs to sign it and requesting a signature at the time of specifying who the signer is gets all messed up if more than one account needs to sign something.
TL;DR
The first example is simple because it hides the stuff happening in the other example.
Answers to your question:
1 - they are the same
2 - browser use fcl, node you will need to implement your own signing function, you shouldnt be able to sign transactions on behalf of your users from node, as currently that would require you to have their private keys and you shouldnt ever have that.
3 - if the minter account was an fcl compatible account (blocto?) it could mint things from the browser using the first one, other wise you will need a node based signing function and provide that node service your private key