fix(output): dvc update should honor output cache flag

[ChillarAnand]

closes #10506

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.99%. Comparing base (2431ec6) to head (be98101).
⚠️ Report is 213 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10964      +/-   ##
==========================================
+ Coverage   90.68%   90.99%   +0.31%     
==========================================
  Files         504      505       +1     
  Lines       39795    41108    +1313     
  Branches     3141     3257     +116     
==========================================
+ Hits        36087    37407    +1320     
- Misses       3042     3063      +21     
+ Partials      666      638      -28     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eeshsaxena]

The change is consistent with the stated goal, and importantly it's a narrow one: use_scm_ignore returns self.use_cache or self.stage.is_repo_import, and for a normal import use_cache defaults to True, so the is_repo_import clause only ever changed behaviour when the user explicitly set cache: false. Dropping it means a cache: false repo-import output is no longer force-gitignored, which is exactly "honor the cache flag" - a cache: false output should be tracked by git, like any other non-cached output. Cached imports (the default) still get ignored via use_cache, so the common path is unchanged.

The one thing I'd want a maintainer to confirm is whether repo-imports were deliberately gitignored independent of caching for some import-specific reason (the clause reads like it was added on purpose rather than incidentally). I couldn't find one - is_repo_import shows up elsewhere in cache/checkout logic (e.g. output.py:1158, stage/__init__.py), but nothing that obviously requires the gitignore decision to differ from a regular output once use_cache is respected. If there is such a reason, this would need to stay conditional; if not, the simplification is the right fix.

On the test: it asserts the entry is removed from .gitignore, which shows the ignore side, but it might be worth also asserting the positive - that after dvc update with cache: false, imported_file is actually tracked/stageable by git (e.g. shows up in scm.status() or isn't ignored via scm.is_tracked/dvc.scm.is_ignored). That pins the user-visible outcome ("my un-cached import is in git") rather than only the .gitignore contents.

Deferring to the maintainers on the import-semantics question - the logic itself looks right to me.