Issue #6982 : Add SAS token authentication to the Azure VFS plugin

[vbhanuchander-lang]

Closes #6982.

Why

The Azure connection could authenticate with a storage account key or a managed identity. An
account key grants full, non-expiring access to the entire storage account, which is what #6982
raises: organisations that have to enforce least privilege cannot use it, and a managed identity is
not always available (external orchestration, on-prem Hop, short-lived access handed to a third
party).

A shared access signature is scoped to specific resources and permissions and carries an expiry,
and is what Microsoft recommends for application-level access to Storage.

What changed

• AzureMetadataType — new sasToken property, @HopMetadataProperty(password = true) so it
  is encrypted at rest and masked in the UI, exactly like storageAccountKey.
• AzureFileProvider — a "SAS Token" branch that resolves variables, decrypts, and passes the
  token to DataLakeServiceClientBuilder.sasToken(...), with a clear error when the field is empty.
  It mirrors the existing Key branch.
• AzureMetadataTypeEditor — "SAS Token" added to the authentication type combo, plus a
  PasswordTextVar shown only for that type, following the existing show/hide pattern for the
  account key.
• Docs — the three authentication types were not documented on the Azure VFS page at all, so I
  added a table covering Key, Managed Identity and SAS Token, plus a short SAS section on how
  to generate one and the expiry caveat.

Two deliberate non-changes:

• No normalisation of the token. The SDK javadoc for sasToken(String) states the value "should
  only be the query parameters (with or without a leading '?') and not a full url", so stripping a
  leading ? myself would be redundant. I verified sasToken(java.lang.String) exists on
  DataLakeServiceClientBuilder in the version we depend on (azure-storage-file-datalake 12.20.0)
  rather than assuming it.
• The global hop-config.json path is untouched. That path only has account/key and no
  authentication type, so adding SAS there is a separate change to AzureConfig and the options
  dialog. Happy to follow up if you'd like it there too.

Backward compatibility

Existing connections keep working unchanged. The AzureMetadataType constructor still defaults
authenticationType to "Key", and the provider still treats an empty authentication type as
"Key". keyAuthenticationRemainsTheDefault pins both.

Testing

New AzureSasTokenAuthenticationTest (4 tests):

Test	Asserts
sasTokenIsStoredOnTheConnectionMetadata	the token round-trips on the metadata type
sasTokenIsMarkedAsAPassword	password = true is present — the option is pointless if the token lands in metadata in clear text
storageAccountKeyRemainsAPassword	the account key keeps the same protection
keyAuthenticationRemainsTheDefault	a new connection still defaults to Key and carries no SAS token

mvn test -pl plugins/tech/azure → 91 tests, 0 failures. spotless:check and
apache-rat:check are clean on the module.

I could not exercise a live SAS handshake without an Azure account, so the credential path itself is
covered by the empty-token guard and by mirroring the key branch; if you have a storage account
handy, a manual check against a real signature would be worth doing before merge.

🤖 AI-assisted changes — generated with Claude Code (Opus 5) and reviewed by me before submitting.