chore(ci): narrow Docker image builds to changed contexts

[laipz8200]

Important

1. Make sure you have read our contribution guidelines
2. Ensure there is an associated issue and you have been assigned to it
3. This PR is part of [Refactor/Chore] Optimize GitHub Actions CI cost across backend, web, VDB, and Docker lanes #34212. It intentionally does not use Fixes #34212 because the umbrella issue will remain open for follow-up CI optimization PRs.

Summary

Part of #34212.

• build only the changed Docker image on PRs, on amd64 only
• publish API and web images independently on push flows
• preserve full multi-arch publish semantics for release tags

Screenshots

Before	After
N/A	N/A

Checklist

• This change requires a documentation update, included: Dify Document
• I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I ran make lint and make type-check (backend) and cd web && npx lint-staged (frontend) to appease the lint gods

Validation

• Parsed .github/workflows/docker-build.yml and .github/workflows/build-push.yml with Ruby's YAML loader.
• PR branch behavior: only build the changed Docker context on pull requests, and only on linux/amd64.
• Push behavior: API and web image publishing run independently on branch pushes; release tags still publish both images with multi-arch manifests.

Release Risk

• Branch pushes no longer rebuild both images when only one Dockerfile changes; this is intentional cost reduction.
• Release tags still go through the full publish path for API and web, so tag-based release semantics remain intact.
• The main risk is if a future branch-based release process depends on the old always-build behavior; that path should use tag pushes or another explicit trigger instead.