Add FileUpload overload to Agent Task Message Builder

[krupybalu]

Summary

Adds an AddAttachment(File: FileUpload) overload to the Agent Task Message
Builder SDK (codeunits 4316 / 4311). This lets callers add attachments
straight from a fileuploadaction, which is what enables multi-file
attachment upload in the Agent Designer (see the companion platform PR).

MIME type is derived from the file name; content is read with MS-DOS
encoding to keep binary attachments byte-safe (matches the Email SDK).

Testing

Added SDK unit tests covering the MIME-type derivation helper and chained
multi-attachment adds.

Work item: AB#632807

What & why

Linked work

Fixes #

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Risk & compatibility

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

FileUpload overload cannot mark attachment as ignored

All other AddAttachment overloads expose an Ignored: Boolean parameter (and optionally IgnoredReason) so callers can flag attachments for non-processing. The new FileUpload overload unconditionally attaches the file as non-ignored, preventing callers that receive a FileUpload from a page trigger from ever marking it as ignored without first converting it to an InStream manually.

Recommendation:

• Add a second AddAttachment(File: FileUpload; Ignored: Boolean) overload (and optionally one with IgnoredReason) that delegates to the internal impl with the appropriate flag, consistent with the API surface of the other overloads.

Suggested change

	procedure AddAttachment(File: FileUpload): codeunit "Agent Task Message Builder"
	procedure AddAttachment(File: FileUpload; Ignored: Boolean): codeunit "Agent Task Message Builder"
	begin
	FeatureAccessManagement.AgentManagementAllowed(true);
	AgentTaskMsgBuilderImpl.AddAttachment(File, Ignored);
	exit(this);
	end;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Silent discard of empty-filename FileUpload

When File.FileName is empty the method silently returns this with no log, trace, or error. In a fluent chain a caller cannot distinguish between a successful attach and a silently dropped file, making production issues (e.g. a FileUpload object that loses its name) invisible.

Recommendation:

• Add a telemetry or session log entry before the early exit so that empty-name uploads appear in diagnostic traces. If an empty filename always indicates a programming error rather than a valid edge case, consider raising an error instead.

Suggested change

	if FileName = '' then
	FileName := File.FileName;
	if FileName = '' then begin
	Session.LogMessage('0000XXX', 'FileUpload AddAttachment skipped: empty file name.', Verbosity::Warning, DataClassification::SystemMetadata, TelemetryScope::ExtensionPublisher, 'Category', 'Agent');
	exit(this);
	end;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Silent filename truncation loses trailing extension

CopyStr(FileName, 1, 250) silently truncates file names longer than 250 characters before storing them. If the extension falls beyond character 250 the stored name has no extension, which means GetContentTypeFromFilename would return an empty MIME type when that same name is later inspected, and MIME-type detection on the full name (line 192) diverges from what is actually stored.

Recommendation:

• Either validate that the filename does not exceed 250 characters and surface an error to the caller, or at least ensure the extension is preserved after truncation. A simple guard would be to raise an error with a descriptive message when the filename is too long.

Suggested change

	CopyStr(FileName, 1, 250),
	if StrLen(FileName) > 250 then
	Error('File name ''%1'' exceeds the maximum allowed length of 250 characters.', FileName);
	AddAttachment(
	CopyStr(FileName, 1, 250),
	CopyStr(GetContentTypeFromFilename(FileName), 1, 100),
	FileInStream);

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Test uses wrong overload for FileUpload scenario

The test AddAttachmentChainedMultipleTimesAddsAllFiles is described as verifying the behaviour of repeated calls "as a fileuploadaction trigger would issue, looping over List of [FileUpload]" but actually invokes the string-based InStream overload (AddAttachment('first.txt', 'text/plain', InStream1)). The new AddAttachment(File: FileUpload) overload introduced in this PR has zero unit-test coverage.

Recommendation:

• Replace the two AddAttachment(name, mime, stream) calls with a mock or stub FileUpload value (or use an integration-test approach that supplies a real FileUpload). At a minimum, add a separate test that exercises the new overload end-to-end so that encoding, MIME-type derivation, and the silent-skip-on-empty-name branch are all covered.

Suggested change

	.AddAttachment('first.txt', 'text/plain', InStream1)
	// Replace lines 1427-1428 with calls that use the FileUpload overload,
	// e.g. via a helper that populates a FileUpload from a TempBlob,
	// or rename this test and add a separate test for FileUpload.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}