refactor: add enum support in blas/base/dtrmv

[DivitJain26]

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown_pkg_readmes status: na
• task: lint_markdown_docs status: na
• task: lint_markdown status: na
• task: lint_package_json status: na
• task: lint_repl_help status: na
• task: lint_javascript_src status: passed
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: na
• task: lint_javascript_benchmarks status: na
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: na
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: na
• task: lint_typescript_declarations status: passed
• task: lint_typescript_tests status: na
• task: lint_license_headers status: passed ---

Resolves #{{TODO: add issue number}}.

Description

What is the purpose of this pull request?

This pull request:

• Resolves option arguments (order, uplo, trans, and diag) prior to dispatching to the underlying implementation in blas/base/dtrmv.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• #{{TODO: add related issue number}}

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

• Are the resolver function names (resolveLayout, resolveTriangle, resolveTranspose, and resolveDiagonal) consistent with project naming conventions, or would different names be preferred?
• I introduced the local variables l, u, t, and d to hold the resolved options. Are these names acceptable, or would more descriptive variable names be preferred?
• Should the layout option be resolved, as it is not passed directly to the base implementation?

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

{{TODO: add disclosure if applicable}}

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/base/dtrmv	$\\color{green}495/495$ $\\color{green}+100.00\\%$	$\\color{green}77/77$ $\\color{green}+100.00\\%$	$\\color{green}3/3$ $\\color{green}+100.00\\%$	$\\color{green}495/495$ $\\color{green}+100.00\\%$

The above coverage report was generated for the changes in this PR.

[kgryte]

LGTM. Thanks, @DivitJain26!