Fix unnecessary loading of directory data for config directives

[mcjwsk]

Description

This pull request optimizes the configDirective() method in Magento\Email\Model\Template\Filter by eliminating redundant calls to retrieve the store information object.

Previously, getStoreInformationObject() was executed every time the directive was processed, even within the same request scope. This resulted in unnecessary repeated instantiation and data fetching.

The change introduces a private cache ($storeInformationObject) along with a dedicated accessor method getStoreInformationObject($storeId) that lazily loads and reuses the object.

Additionally:

• Store information retrieval is now deferred until it is actually needed.
• Minor readability improvements were applied (e.g., simplifying region fallback logic).
• Avoided redundant $store and $storeInformationObj initialization when not required.

This improves performance and reduces overhead when processing email templates with multiple config directives.

---

Related Pull Requests

N/A

---

Fixed Issues

N/A

---

Manual testing scenarios

1. Configure store information in admin panel:

   • Stores → Configuration → General → Store Information
   • Set values for country and region.

2. Create or modify an email template containing:

   {{config path="general/store_information/country_id"}}
   {{config path="general/store_information/region_id"}}
   

3. Trigger an email that uses this template (e.g. order confirmation).

4. Verify that:

   • Country and region values are correctly rendered.
   • Region fallback works correctly when region is not explicitly set.

5. (Optional) Add logging or use profiler to confirm:

   • getStoreInformationObject() is executed only once per filter instance.

---

Questions or comments

This change assumes that storeInformationObject can be safely reused within a single Filter instance lifecycle. Please confirm that there are no edge cases where multiple store contexts could be processed within the same instance.

---

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any required sections need an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @mcjwsk. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[mcjwsk]

@magento run all tests