lacerto

If you want to have exactly 6 levels then you need to combine the Posterize adjustment with Gradient and Black & White adjustments (the last one being useful when working with a color image). The exact number of levels will then be determined by the Posterize adjustment while the Gradient adjustment determines the color scale. With Black & White adjustment you can determine the brightness level of primaries and how they interact with the defined gradient:

exactnumberofshades.mp4 You can use the Histogram to check the number of levels in the image, or create a document palette (note that only max 64 tones/colors will be created). Often it is also necessary to add a solid layer at the bottom of the design (I suppose in situations an image has partial transparencies). If exact number of levels is not required, then the shown methods will produce appearance of decreased levels and are adequate.

If you want to have exactly 6 levels then you need to combine the Posterize adjustment with Gradient and Black & White adjustments (the last one being useful when working with a color image). The exact number of levels will then be determined by the Posterize adjustment while the Gradient adjustment determines the color scale. With Black & White adjustment you can determine the brightness level of primaries and how they interact with the defined gradient:

exactnumberofshades.mp4 You can use the Histogram to check the number of levels in the image, or create a document palette (note that only max 64 tones/colors will be created). Often it is also necessary to add a solid layer at the bottom of the design (I suppose in situations an image has partial transparencies). If exact number of levels is not required, then the shown methods will produce appearance of decreased levels and are adequate.

That is fine, but it is good to know that this does not cover effect of blends and overprints so an exported output can have exceeding coverages not spotted by the preflight calculator.

Have you tried the save, close and reopening trick, as advised by @thomaso. This should result in RGB images being properly assigned with the "new" (currently active) target CMYK profile so that you get correct reading already when using TAC picker or CMYK picker, but most importantly, when you actually export to CMYK PDF. 

Make sure that you also have "Look inside placed documents" checked! Note however that this tool does not take into account the effect of blend modes and overprints so the total outcome of an exported file can still exceed the set TAC limit without any warnings displayed.

If your blacks are RGBs, basically just applying (assigning) an appropriate color profile would limit the total ink to a specific maximum value. If the max TAC is as low as 260% you appear to have uncoated (or very lightly coated) media. Choosing e.g. US Web Uncoated would limit the total ink to 251% and keep the job neutral, not making it diluted or desaturated but basically just limiting excessive ink in darkest areas.
If your colors are already in CMYK, you may consider converting the job (color definitions) to RGB, and then choose an appropriate profile in context of the press conditions and media that limits the total area coverage and manages ink usage with proper methods (like applying undercolor removal and gray color replacement curves). (Converting from CMYK to CMYK is normally not a good idea but if there are clear spots with excessive ink you might get away with it by applying manual tone control.) 
But my point is: by using an appropriate profile you will get balanced (non-color cast) properly managed tones and will get excessive ink usage automatically limited. Playing with soft proof and manual tone controls can be useful in RGB based output workflows (that expect the print file to be in RGB color mode), but typically not when using  commercial press. 
See below how changing from an app. max 330% TAC Euroscale Coated profile to US Web Uncoated effectively limits the inks to max 250%.

limitingtac.mp4 Note how Affinity apps appear to require refreshing of placed RGB images before ink limit of a changed profile takes effect (something that does not happen when using e.g. InDesign, so there both early and export-time profile reassignments are correctly applied for RGB objects when exporting to PDF) -- I have a feeling that this did not happen earlier within Affinity apps, either. It also seems that the macOS versions are even more broken as there (at least with native chip on macOS Sonoma 14.24.1 and latest Publisher 2.4.2) assigning a different CMYK profile does not seem to have effect on conversion of neither native art in RGB color mode (the RGB 0, 0, 0 black rectangle), nor in RGB image, so on macOS profile-based TAC limiting is badly broken.
Note that US based profile may not be ideal in European press so you could ask your printer if they have a recommendation for the output profile considering the press conditions and used media. 
UPDATE: It seems that on macOS the native objects can be "reassigned" (refreshed) at least by selecting them and switching the color model within the Color panel (without making color conversion). On Windows "refreshing" is not needed (and should not be required on macOS, either).
UPDATE2: Sorry, I read your initial message a bit carelessly and thought that TAC 260 was the goal, instead of TAC 280. You can come pretty close with e.g. Uncoated_Fogra47L_ViGC_300.icc, which has 274% as the TAC.

What a nasty issue. It also occurs to me in APub V1. After assigning the other document profile then switching the colour model in the Colours Panel does not refresh the image and TAC values (but applies a fill colour, even if the wells are set to none before). Instead I can either replace the image (which is not useful) or save + close + reopen the document to get the profile with correct colour values / TAC displayed. Without this additional workaround also an export shows the values of the former document profile (when placing the image) though PDF/X-1 is using the correct intent for export.

If your blacks are RGBs, basically just applying (assigning) an appropriate color profile would limit the total ink to a specific maximum value. If the max TAC is as low as 260% you appear to have uncoated (or very lightly coated) media. Choosing e.g. US Web Uncoated would limit the total ink to 251% and keep the job neutral, not making it diluted or desaturated but basically just limiting excessive ink in darkest areas.
If your colors are already in CMYK, you may consider converting the job (color definitions) to RGB, and then choose an appropriate profile in context of the press conditions and media that limits the total area coverage and manages ink usage with proper methods (like applying undercolor removal and gray color replacement curves). (Converting from CMYK to CMYK is normally not a good idea but if there are clear spots with excessive ink you might get away with it by applying manual tone control.) 
But my point is: by using an appropriate profile you will get balanced (non-color cast) properly managed tones and will get excessive ink usage automatically limited. Playing with soft proof and manual tone controls can be useful in RGB based output workflows (that expect the print file to be in RGB color mode), but typically not when using  commercial press. 
See below how changing from an app. max 330% TAC Euroscale Coated profile to US Web Uncoated effectively limits the inks to max 250%.

limitingtac.mp4 Note how Affinity apps appear to require refreshing of placed RGB images before ink limit of a changed profile takes effect (something that does not happen when using e.g. InDesign, so there both early and export-time profile reassignments are correctly applied for RGB objects when exporting to PDF) -- I have a feeling that this did not happen earlier within Affinity apps, either. It also seems that the macOS versions are even more broken as there (at least with native chip on macOS Sonoma 14.24.1 and latest Publisher 2.4.2) assigning a different CMYK profile does not seem to have effect on conversion of neither native art in RGB color mode (the RGB 0, 0, 0 black rectangle), nor in RGB image, so on macOS profile-based TAC limiting is badly broken.
Note that US based profile may not be ideal in European press so you could ask your printer if they have a recommendation for the output profile considering the press conditions and used media. 
UPDATE: It seems that on macOS the native objects can be "reassigned" (refreshed) at least by selecting them and switching the color model within the Color panel (without making color conversion). On Windows "refreshing" is not needed (and should not be required on macOS, either).
UPDATE2: Sorry, I read your initial message a bit carelessly and thought that TAC 260 was the goal, instead of TAC 280. You can come pretty close with e.g. Uncoated_Fogra47L_ViGC_300.icc, which has 274% as the TAC.

I remembered incorrectly the capability of Ghostscript to show overprint state of spot colors (especially ones in PDF/X-based exports), but it seems that they do not form a special case.
Ghostscript does have similar issues as Adobe Acrobat Pro with ICC-dependent PDFs without output intent (causing ad-hoc recalculated color values shown based on underlying default target), and therefore -- and because of lack of more general interest in the app on the forum, much because it requires user-initiated installation of Ghostscript -- I did not continue developing of my GS front end PDF Output Preview, so it has not been touched in about two and a half years.
But considering the continuing poor availability of free (or even low-cost) professional prepress tools being able to show e.g. spot colors, pick color values, show total area coverage and overprints, I decided to update the tool, and it now supports also version 2 Affinity apps on both Windows and macOS.
The tool has more "advanced" features on Windows, but might be useful also on macOS. It has been only cursorily tested on most recent Affinity v2 apps (2.2.0 and 2.2.1) on up-to-date Windows 11 Pro and macOS Sonoma 14.0. I had GS 9.5.0 installed on macOS Sonoma and it seems to work fine. On Windows I tested it with GS 9.56.1.
To avoid the mistargeting issue, it is recommended -- as always when producing DeviceCMYK content -- that ICC profiles are NOT embedded in the PDF exports (unless done automatically when using PDF/X-routines where inclusion of output intent is obligatory and happens automatically).
The apps are not properly digitally signed, and as mentioned, not really tested, but I can try to help forum users interested in using the app and needing some assistance. 

autokoverprint_wspots.pdf
Windows version (1.0.0.17):
POPWin_v17.zip

NOTE: The app can read PANTONE rendering colors only for MSI-based Affinity v2 apps (because the PANTONE .csvs are sandboxed in Windows store versions and their installation locations change with each updated version). 
macOS version (1.0.0.13):
PDF Output Preview-1.0.0.13.pkg
NOTE: The apps have been written in C# so they require runtimes. I am not sure but I think that both Win and macOS latest versions have runtimes installed.
 

As @walt.farrell suggested, holding down the Alt/Option key while using the Text tool (either Frame or Artistic), lets you alternate between overlapping text layers (the focus changes on each time clicked so if you want to select text, do it when you Alt+click the correct frame). If the Move tool is used, instead, the selection will alter between all overlapping layers (not just text layers).  

Interestingly, forcing conversion of image color spaces in context of PDF/X-based export methods also seems to restitute the "K-Only" effect for "K-Only" images that have adjustments applied (and which otherwise result in conversion to four-color state when exported). When examined in Adobe Acrobat, such objects seem to have both grayscale and K-ink version of a CMYK image included in PDF/X-4 and all non-PDF/X based export methods, but the values show as K-values only in PDF/X based versions. PDF/X-1 and X-3 only have the CMYK K-ink included. This is quite confusing (and also feeble, knowing the restrictions involved in PDF/X-based export methods). 

I had another look on this, and now on macOS. There I first changed number formatting to US English style using System Regional settings (from the default Finnish one), and then simply just opened your .XLSX file in Microsoft Excel (latest version). The formatting came correct out of the box, including the date, and surprisingly were not "custom" formats in macOS Excel (which, btw, in many ways seems smarter than its Windows cousin). So what I did was that I just copied the Excel data onto Clipboard, selected all cells in Publisher imported .XLSX file that is otherwise properly formatted, just messing up number formats, and pasted. Alignments come wrong, but it is a simple task to right align required columns, and vertically center align cells.

pastefromexcel.mp4   On Windows (using Finnish regional settings, at least), I had to open the .XLSX file in Excel and change number and date formatting that were interpreted as "custom" to standard US formats, and save back. After that, Publisher opened the file correctly (excluding alignments). On Windows, you can also use Clipboard to transfer correctly formatted data via Clipboard (using the default Rich Text Format), but on Windows reformatted .XLSX is read correctly (on macOS it will still be read incorrectly).

I was referring to any object with an outside-aligned FX Outline. The object is composited over an outline-coloured dilated silhouette of the object.  Reducing the opacity of the object's fill colour results in the fill being blended with the silhouette instead of concealing the silhouette.

The behaviour in the OP's video is the "by design" (as Serif would say) result of the implementation of FX Outline.

Well, it seems it cannot, not at least the test versions that I created from Affinity Photo version 1 and 2, with 5 pixel layers. The default Zip compressed TIFF file additionally showed the active layer with pixel content as corrupt (and no other layers present). LZW and non-compressed TIFFs were shown correctly but the empty layers were not present. And as mentioned, Affinity Photo 1 cannot open TIFF files created from within Affinity Photo 2 with Affinity layers (because they cannot open Affinity Photo 2 files).
So the key to the "layer mystery" and why Photopea, indeed, is a solution to share Affinity layers with ANY user (not just Windows!) that have an image editor capable of opening a Photoshop files with layers -- is that Photopea can open native Affinity Photo v1 and v2 files and save them as  standard .PSD files with layers that any app supporting PSD import (with layers) can open. So Photopea basically does the job that Affinity Photo should do in the first place!
Because Photopea does what it does, one begins to wonder, but hopefully Ivan Kutskir still is (and stays!) independent and just has managed to de-engineer .aphoto format (as he once did with .PSD format before it was partially publicly documented). For more information on Photoshop format and apps that support PSD format, see e.g. https://www.loc.gov/preservation/digital/formats/fdd/fdd000523.shtml. 

I think we have exchanged some thoughts earlier about degree of usefulness of IDML serving as a kind of an exchange format between different layout apps (considering how it is currently implemented e.g. in QXP and VivaDesigner), but I certainly agree with you that these kinds of "incompatibility" concerns are silly.
IMO, speculations of "proprietary" or "nondisclosure" issues related to IDML are equally nonsensical. I am not sure how Adobe handles downgrading of features so that "new", post CS4-features get at some level included, but I have understood that IDML specs basically do not get upgraded because the idea is that layouts saved in IDML format, including ones saved in latest CC versions, can be opened also in CS4. If something is not "understood" by earlier versions, it is just skipped/ignored, .
As for reasons of current non-availability of (over a decade old) IDML specs on Adobe dev network (while IDML tools and cookbook are still available), we can only make guesses, but anyone googling IDML File Format specs gets the needed documentation as second and third find entry on Github and CreativePro (not particularly dark internet)... IDML file format itself is nothing more than zipped XML = plain text, so anybody can see how ID features are expressed in mark up. If Serif can convert that to native Affinity objects there is nothing in the technology that stops them doing it in the other direction. 

It seems it has been possible to Adobe developers at least from 2012 (InDesign CS6):

importing_custom_formatted_excel.mp4   The clip is from Windows that uses Finnish regional settings with space and comma as group and decimal separator, and as text is interpreted rather than using live formats, needs to be find-replaced to set formats correctly. InDesign would probably read the file correctly if system regional settings were changed and the app restarted. 
InDesign reads the custom formats meaningfully both from .XLS and .XLSX formats, so I think this is basically just a question of maturity of apps, and level of programming skills.

It seems it has been possible to Adobe developers at least from 2012 (InDesign CS6):

importing_custom_formatted_excel.mp4   The clip is from Windows that uses Finnish regional settings with space and comma as group and decimal separator, and as text is interpreted rather than using live formats, needs to be find-replaced to set formats correctly. InDesign would probably read the file correctly if system regional settings were changed and the app restarted. 
InDesign reads the custom formats meaningfully both from .XLS and .XLSX formats, so I think this is basically just a question of maturity of apps, and level of programming skills.

@kat
XLS and XLSX are two different file formats of Microsoft Excel Spreadsheet.
The difference is that XLS (2003 Excel) uses a binary format, and XLSX (2007 Excel) uses the newer XML format as a method to save data.
According to "supported file formats for placement" list in the Placing content chapter (official V2 documentation) APub only supports XLSX files.
Placing content (Official V2 APub documentation)
Verifying the above, there is one conclusion. XLS files are not supported and can't be placed in APub.
If you are concerned about incorrectly interpreted cell formatting and blank lines, which is not the case in the PDF version generated in Excel, then:
When it comes to misinterpreting the formatting, this has always been a problem and until it is improved there is not much the user can really do.
I get around this problem by copying the values directly from spreadsheet to a previously prepared table in APub (appropriate number of columns, rows, style).
It requires more work but the formating is exactly how iit should be.
If I really have to use an XLSX file, I try to make sure it does not have non-standard formatting in cells, only values and text.
I work out the formatting and details in APub itself.
  For blank rows, APub did the job correctly. There are also blank lines in the XLSX file, so they have been mapped to match the original.
There are no blank lines in the PDF because perhaps Excel exports to PDF by default by removing blank lines or offers such an option when exporting.
I'm not sure because I gave up Office a long time ago and now im using OpenOffice. example video — copying from spreadsheed to table prepared in APub↓
This is posible because spreadsheet data is copied as tabular data - that's what @lacerto mentioned.

Apub_copy_from_spreadsheet.mp4 @lacerto im not an expert of XLSX file format but is it even possible for APub to map the custom number formatting from an Excel XLSX file?
I always thought it was impossible, that it could only retrieve the plain value, but how would it know what rules to apply to get the right format?
I think XLSX only contains a reference to the formatting style, not the actual rules that create that formatting. These are probably saved in Excel.
It wouldn't make sense to save the custom formatting rules in the XLSX file itself. This type of file format implementation would be like 👽

Yes, this seems to happen both on Windows and macOS, so even if the system regional settings match the formatting of the placed (interpreted) Excel document, e.g. the thousands and decimal separators are incorrectly read.
On macOS, one can get correct non-rasterized formatting when copy pasting from Excel (apparently the data will be in PDF format). but editing, if necessary, is pretty cumbersome. On Windows, formatted Excel data will be rasterized, and on both platforms, Excel data can also be pasted as tab separated data and then manually formatted, which is of course tedious, but still one way to get this kind of data formatted according to wishes.
Here's how the attached .xlsx file (with US formatting) will appear on macOS Sonoma 14.2.1 when placed (above) and pasted from Excel (below) in a system that has US regional settings as system settings (and also as language settings in Affinity apps, should that matter at all).
 

If you can reproduce the problem consistently with a specific file (also after having closed and reopened the file, and the app itself, and especially after restarting the computer), it would be useful to post the file for examination of devs.
I have a feeling that the error is somehow related to mouse capture, and for me the error often goes away after I start the app again after it has crashed, or anyway, it cannot be reproduced consistently. But as said, I think that this error has been there as long I have used Affinity apps (and does not happen with any other apps).

Thank you so much for taking the time to do this! As you wrote, it seems a bit tricky with the brush profile and additional tones being created, but I am inspired to dig deeper. Hopefully a future update will include a "recolor" feature to make these sorts of things a bit easier. Thank you again!

It is a bit tricky design as the "additional" orange tones probably cannot be removed with this method without using rasterization, since it seems that the brush profile is applied last, causing smooth transition of edge colors even after quantization curves have been applied. There is additionally opacity and Darken blend mode applied on the brush curve that make the case more complex than one that I used in the demonstration recording.
So depending on the goal the quantization trick shown might require some further modifications (also considering whether the edge colors which are wanted to be reduced are created with direct color definitions or by using modifiers like coloring, opacity and blend modes). The three quantization "parameters" (Gradient Map Adjustment, Posterize Adjustment and Black and White Adjustment) typically also need to be twiddled a while to get the desired effect.
Note that rasterization itself is not a quality compromise since blend modes, effects, vector brushes etc. will cause export time rasterization anyway.
The video clip below demonstrates reduction of the original orange tones from 48 to 2:

orange_reduction.mp4 I have also attached the design you posted with Quantization group added and the required modifications made to achieve what is demonstrated on the video. Note that if you create a document palette with the complete design (texts and the record itself), the number of orange tones increases so obviously there are opacity / smoothening effects elsewhere in the design that cause this.
DiJ 2024_quantization.afdesign

You can do quantization to exact number of colors using a trick that I have shown a couple of times on this forum (earlier video clips probably deleted because of Affinity forum max storage limit), using the Gradient Map, Posterize and Black and White adjustments (in this order) on underlying layers (projected against a solid background):

quantization_brushes.mp4 Note how Affinity apps create a document palette based on effect of adjustments even if part of the manipulated layers fall outside of the background (so that the image actually still has dozens of orange tones, quantized number being effective only within the boundaries of the background rectangle). 

You can do quantization to exact number of colors using a trick that I have shown a couple of times on this forum (earlier video clips probably deleted because of Affinity forum max storage limit), using the Gradient Map, Posterize and Black and White adjustments (in this order) on underlying layers (projected against a solid background):

quantization_brushes.mp4 Note how Affinity apps create a document palette based on effect of adjustments even if part of the manipulated layers fall outside of the background (so that the image actually still has dozens of orange tones, quantized number being effective only within the boundaries of the background rectangle).