fix: use tag-specific complexity reports (#857)

* fix(expand-task): Use tag-specific complexity reports

- Add getTagAwareFilePath utility function to resolve tag-specific file paths
- Update expandTask to use tag-aware complexity report paths
- Fix issue where expand-task always used default complexity report
- Add comprehensive tests for getTagAwareFilePath utility
- Ensure proper handling of file extensions and directory structures

Fixes #850: Expanding tasks not using tag-specific complexity reports

The expandTask function now correctly uses complexity reports specific
to the current tag context (e.g., task-complexity-report_feature-branch.json)
instead of always using the default task-complexity-report.json file.

This enables proper task expansion behavior when working with multiple
tag contexts, ensuring complexity analysis is tag-specific and accurate.

* chore: Add changeset for tag-specific complexity reports fix

* test(expand-task): Add tests for tag-specific complexity report integration

- Introduced a new test suite for verifying the integration of tag-specific complexity reports in the expandTask function.
- Added a test case to ensure the correct complexity report is used when available for a specific tag.
- Mocked file system interactions to simulate the presence of tag-specific complexity reports.

This enhances the test coverage for task expansion behavior, ensuring it accurately reflects the complexity analysis based on the current tag context.

* refactor(task-manager): unify and simplify tag-aware file path logic and tests

- Reformatted imports and cleaned up comments in test files for readability
- Centralized mocks: moved getTagAwareFilePath & slugifyTagForFilePath
  mocks to setup.js for consistency and maintainability
- Simplified utils/getTagAwareFilePath: replaced manual parsing with
  path.parse() & path.format(); improved extension handling
- Enhanced test mocks for path.parse, path.format & reset path.join
  in beforeEach to avoid interference
- All tests now pass consistently; no change in functionality

tests/unit/scripts/modules/task-manager/setup.js

@@ -119,3 +119,45 @@ export const setupCommonMocks = () => {
 
 // Helper to create a deep copy of objects to avoid test pollution
 export const cloneData = (data) => JSON.parse(JSON.stringify(data));
+
+/**
+ * Shared mock implementation for getTagAwareFilePath that matches the actual implementation
+ * This ensures consistent behavior across all test files, particularly regarding projectRoot handling.
+ *
+ * The key difference from previous inconsistent implementations was that some tests were not
+ * properly handling the projectRoot parameter, leading to different behaviors between test files.
+ *
+ * @param {string} basePath - The base file path
+ * @param {string|null} tag - The tag name (null, undefined, or 'master' uses base path)
+ * @param {string} [projectRoot='.'] - The project root directory
+ * @returns {string} The resolved file path
+ */
+export const createGetTagAwareFilePathMock = () => {
+	return jest.fn((basePath, tag, projectRoot = '.') => {
+		// Handle projectRoot consistently - this was the key fix
+		const fullPath = projectRoot ? `${projectRoot}/${basePath}` : basePath;
+
+		if (!tag || tag === 'master') {
+			return fullPath;
+		}
+
+		// Mock the slugification behavior (matches actual implementation)
+		const slugifiedTag = tag.replace(/[^a-zA-Z0-9_-]/g, '-').toLowerCase();
+		const idx = fullPath.lastIndexOf('.');
+		return `${fullPath.slice(0, idx)}_${slugifiedTag}${fullPath.slice(idx)}`;
+	});
+};
+
+/**
+ * Shared mock implementation for slugifyTagForFilePath that matches the actual implementation
+ * @param {string} tagName - The tag name to slugify
+ * @returns {string} Slugified tag name safe for filesystem use
+ */
+export const createSlugifyTagForFilePathMock = () => {
+	return jest.fn((tagName) => {
+		if (!tagName || typeof tagName !== 'string') {
+			return 'unknown-tag';
+		}
+		return tagName.replace(/[^a-zA-Z0-9_-]/g, '-').toLowerCase();
+	});
+};