Previously ParseSecretsFile set EnvName unconditionally to the file key
for every parsed entry. This caused keys that are not valid POSIX env
names (e.g. MY-TOKEN, my.key) or that are reserved (e.g. PATH) to fail
ValidateCreateUserSecretRequest on the env_name field, rolling back the
entire atomic batch import. Common real-world .env files typically
contain such keys.

Change EnvName assignment to best-effort: only set it when the key
passes UserSecretEnvNameValid; otherwise leave EnvName empty. The secret
is still imported, just without env injection. The env_name uniqueness
index is a partial index (WHERE env_name != ''), so multiple empty
env_names are fine.

Update tests:
- Add TestParseSecretsFileEnvBestEffortEnvName in codersdk with cases
  for hyphenated key (MY-TOKEN), reserved name (PATH), dot key (my.key),
  and a valid key (MY_TOKEN).
- Remove ReservedEnvName (PATH) from the rollback failure cases in
  coderd/usersecretsimport_test.go; add
  TestImportUserSecretsReservedEnvNameBestEffort to assert the new
  success behavior (secret created, env_name empty).

…ings

…uide

…240)

Add a file-upload dropzone to the create branch of the Add secret dialog
(edit is unchanged). The browser reads the file, derives the format from
the extension, and calls the import endpoint, surfacing per-entry backend
errors. Includes Storybook coverage for success, partial-failure, and
unsupported-file cases.